CI: build boringssl-static and the FIPS profile on Debian 13, verify both jars on Alpine

Motivation:

CI built boringssl-static only on the two release images and never built the
FIPS profile at all, so #997 could add the musl check to that profile without
the matching link changes and nothing failed until a downstream build did
(#1008).

Modifications:

- docker/Dockerfile.debian13 + docker-compose.debian-13.yaml: `build`
  (default profile) and `build-fips`. The image carries the build environment
  from certificate #5244's security policy, the module the FIPS profile pins:
  clang 17.0.6 and ninja 1.12.1 from the Debian archive, go 1.22.3 and
  cmake 3.29.3 downloaded at those versions. No JDK 8 in trixie: the build
  runs on JDK 21 with the pom's --release 8.
- ci-pr.yml / ci-build.yml: legs debian13-x86_64 and debian13-x86_64-fips,
  and two bare-Alpine musl-verify legs on their jars. The FIPS one is the leg
  with no substitute: the module's integrity check and self-tests run in an
  ELF constructor at dlopen, so only a real load proves the post-link
  patchelf left it intact.
- docker/README.md, docs/musl-compatibility.md.

Result:

A change to the FIPS profile, or to the release profiles that is not ported
to it, fails on the PR. Not a release image: the artifacts have a glibc 2.34
floor.

Author: fredericgermain

.github/workflows/ci-build.yml

@@ -40,6 +40,16 @@ jobs:
           - setup: al2023-x86_64-aws_lc
             docker-compose-run: "-f docker/docker-compose.al2023.yaml run build"
             docker-bake-args: "-f docker-compose.al2023.yaml"
+          # boringssl-static on a current toolchain, and the only CI leg that builds the FIPS
+          # profile (it needs clang-17; see docker/Dockerfile.debian13). Neither is a release
+          # artifact. Before these legs the FIPS profile had no CI at all, so a change to the
+          # release profiles that was not ported to it went unnoticed until a downstream build.
+          - setup: debian13-x86_64
+            docker-compose-run: "-f docker/docker-compose.debian-13.yaml run build"
+            docker-bake-args: "-f docker-compose.debian-13.yaml"
+          - setup: debian13-x86_64-fips
+            docker-compose-run: "-f docker/docker-compose.debian-13.yaml run build-fips"
+            docker-bake-args: "-f docker-compose.debian-13.yaml"
 
     name: ${{ matrix.setup }}
     steps:
@@ -205,6 +215,28 @@ jobs:
             drop-elftools: "0"
             build-service: runtime-setup
             run-service: verify
+          # The Debian 13-built jars: the FIPS artifact is the one that matters (its power-on
+          # self-test and integrity check run inside an ELF constructor at dlopen, so only a
+          # real load proves the patchelf'd library is still intact), and the default-profile
+          # one shows what a modern-gcc build looks like on musl. bare x86_64 only: aarch64
+          # would need an arm64 FIPS build leg, and the gcompat/nolibgcc variants add nothing
+          # the CentOS 6 legs do not already establish.
+          - setup: alpine-x86_64-fips
+            os: ubuntu-24.04
+            jars: build-debian13-x86_64-fips-jars
+            variant: bare
+            extra-pkgs: ""
+            drop-elftools: "1"
+            build-service: runtime-setup
+            run-service: verify
+          - setup: alpine-x86_64-debian13
+            os: ubuntu-24.04
+            jars: build-debian13-x86_64-jars
+            variant: bare
+            extra-pkgs: ""
+            drop-elftools: "1"
+            build-service: runtime-setup
+            run-service: verify
           - setup: glibc-control-x86_64
             os: ubuntu-24.04
             jars: build-centos6-x86_64-jars

.github/workflows/ci-pr.yml

@@ -38,6 +38,16 @@ jobs:
           - setup: al2023-x86_64-aws_lc
             docker-compose-run: "-f docker/docker-compose.al2023.yaml run build"
             docker-bake-args: "-f docker-compose.al2023.yaml"
+          # boringssl-static on a current toolchain, and the only CI leg that builds the FIPS
+          # profile (it needs clang-17; see docker/Dockerfile.debian13). Neither is a release
+          # artifact. Before these legs the FIPS profile had no CI at all, so a change to the
+          # release profiles that was not ported to it went unnoticed until a downstream build.
+          - setup: debian13-x86_64
+            docker-compose-run: "-f docker/docker-compose.debian-13.yaml run build"
+            docker-bake-args: "-f docker-compose.debian-13.yaml"
+          - setup: debian13-x86_64-fips
+            docker-compose-run: "-f docker/docker-compose.debian-13.yaml run build-fips"
+            docker-bake-args: "-f docker-compose.debian-13.yaml"
 
     name: ${{ matrix.setup }}
     steps:
@@ -267,6 +277,28 @@ jobs:
             drop-elftools: "0"
             build-service: runtime-setup
             run-service: verify
+          # The Debian 13-built jars: the FIPS artifact is the one that matters (its power-on
+          # self-test and integrity check run inside an ELF constructor at dlopen, so only a
+          # real load proves the patchelf'd library is still intact), and the default-profile
+          # one shows what a modern-gcc build looks like on musl. bare x86_64 only: aarch64
+          # would need an arm64 FIPS build leg, and the gcompat/nolibgcc variants add nothing
+          # the CentOS 6 legs do not already establish.
+          - setup: alpine-x86_64-fips
+            os: ubuntu-24.04
+            jars: build-pr-debian13-x86_64-fips-jars
+            variant: bare
+            extra-pkgs: ""
+            drop-elftools: "1"
+            build-service: runtime-setup
+            run-service: verify
+          - setup: alpine-x86_64-debian13
+            os: ubuntu-24.04
+            jars: build-pr-debian13-x86_64-jars
+            variant: bare
+            extra-pkgs: ""
+            drop-elftools: "1"
+            build-service: runtime-setup
+            run-service: verify
           # Control: anything failing on Alpine must pass here, or the check is at fault rather
           # than the artifact.
           - setup: glibc-control-x86_64

docker/Dockerfile.debian13

@@ -0,0 +1,72 @@
+ARG debian_version=13
+FROM debian:$debian_version
+# needed to do again after FROM due to docker limitation
+ARG debian_version
+ARG go_version=1.22.3
+ARG cmake_version=3.29.3
+ENV GO_VERSION $go_version
+ENV CMAKE_VERSION $cmake_version
+ENV DEBIAN_FRONTEND noninteractive
+
+# A modern glibc builder for boringssl-static, and the only in-tree image that can build the
+# fips-boringssl-static profile. That profile pins the BoringCrypto module that holds
+# certificate #5244, and this image carries the build environment its security policy names:
+#   clang 17.0.6, go 1.22.3, ninja 1.12.1, cmake 3.29.3
+# Debian 13 packages clang-17 at exactly 17.0.6 and ninja at exactly 1.12.1. Its cmake (3.31)
+# and Go (1.24) are newer than the policy's, so those two come from cmake.org and go.dev at the
+# policy's versions instead. patchelf 0.18 has --remove-needed; APR's buildconf wants the
+# `libtool` script, which is in libtool-bin.
+#
+# No JDK 8 in trixie: the build runs on JDK 21. The pom compiles with --release 8, so the
+# class files are still Java 8.
+#
+# Not pinned to linux/amd64 like the older images, so it can also be built natively on an
+# arm64 host for a quick local run. CI builds it on amd64 runners.
+#
+# Unlike the CentOS 6 image this is NOT a release builder: its artifact has a glibc 2.41 floor.
+# It exists to give the boringssl-static and FIPS builds CI coverage on a current toolchain.
+RUN apt-get update && apt-get install -y --no-install-recommends \
+ autoconf \
+ automake \
+ bzip2 \
+ ca-certificates \
+ clang-17 \
+ curl \
+ g++ \
+ gcc \
+ git \
+ gnupg \
+ libapr1-dev \
+ libtool \
+ libtool-bin \
+ make \
+ ninja-build \
+ openjdk-21-jdk-headless \
+ patch \
+ patchelf \
+ perl \
+ pkg-config \
+ tar \
+ unzip \
+ wget \
+ xz-utils \
+ zip \
+ && rm -rf /var/lib/apt/lists/*
+
+# dpkg's amd64/arm64 spelling matches go.dev's; cmake.org spells the arch x86_64/aarch64.
+RUN ARCH=$(dpkg --print-architecture) && case $ARCH in amd64) CM=x86_64;; arm64) CM=aarch64;; esac \
+ && wget -q https://go.dev/dl/go$GO_VERSION.linux-$ARCH.tar.gz \
+ && tar -C /opt -xzf go$GO_VERSION.linux-$ARCH.tar.gz && rm go$GO_VERSION.linux-$ARCH.tar.gz \
+ && wget -q https://github.com/Kitware/CMake/releases/download/v$CMAKE_VERSION/cmake-$CMAKE_VERSION-linux-$CM.tar.gz \
+ && tar -C /opt -xzf cmake-$CMAKE_VERSION-linux-$CM.tar.gz && rm cmake-$CMAKE_VERSION-linux-$CM.tar.gz \
+ && ln -s /opt/cmake-$CMAKE_VERSION-linux-$CM /opt/cmake \
+ && ln -s /usr/lib/jvm/java-21-openjdk-$ARCH /usr/lib/jvm/java-21
+# The compose services run `bash -cl`, and Debian's /etc/profile resets PATH for login shells,
+# so ENV PATH alone is not enough: root's ~/.profile sources ~/.bashrc, which restores it.
+ENV PATH /opt/go/bin:/opt/cmake/bin:$PATH
+RUN echo 'export PATH=/opt/go/bin:/opt/cmake/bin:$PATH' >> ~/.bashrc
+ENV JAVA_HOME /usr/lib/jvm/java-21
+RUN go version && clang-17 --version | head -1 && ninja --version && cmake --version | head -1
+
+# /code is a bind mount owned by the host user; newer git refuses to touch it otherwise.
+RUN git config --global --add safe.directory '*'

docker/README.md

@@ -39,6 +39,20 @@ docker compose -f docker/docker-compose.opensuse.yaml -f docker/docker-compose.o
 docker compose -f docker/docker-compose.centos-7.yaml run cross-compile-aarch64-build
 ```
 
+## Debian 13 with java 21: boringssl-static on a current toolchain, and the FIPS profile
+
+Not a release builder (glibc 2.41 floor). It is the one image that can build the
+`fips-boringssl-static` profile, and it carries the build environment named by the security
+policy of the certificate that profile pins (#5244): clang 17.0.6 and ninja 1.12.1 from the
+archive, go 1.22.3 and cmake 3.29.3 downloaded at those versions. Both services stop at
+`package`, which is where the musl compatibility check runs. Not pinned to amd64, so on an
+arm64 host it builds natively.
+
+```
+docker compose -f docker/docker-compose.debian-13.yaml run build
+docker compose -f docker/docker-compose.debian-13.yaml run build-fips
+```
+
 etc, etc
 
 

docker/docker-compose.debian-13.yaml

@@ -0,0 +1,44 @@
+version: "3"
+
+# Debian 13 builder. Two things run here that no other image covers, see Dockerfile.debian13:
+#   build       boringssl-static (default profile) on a current gcc, so the Linux native
+#               build is exercised somewhere other than the CentOS 6 release image
+#   build-fips  the fips-boringssl-static profile, which needs clang-17
+# Both stop at `package`, which is where the native-jar musl check runs.
+
+services:
+
+  runtime-setup:
+    image: netty-tcnative-debian:13
+    build:
+      context: ../
+      dockerfile: docker/Dockerfile.debian13
+      args:
+        debian_version: "13"
+
+  common: &common
+    image: netty-tcnative-debian:13
+    depends_on: [runtime-setup]
+    environment:
+      - MAVEN_OPTS
+    volumes:
+      - ~/.m2/repository:/root/.m2/repository
+      - ..:/code:delegated
+    working_dir: /code
+
+  build:
+    <<: *common
+    command: /bin/bash -cl "./mvnw -am -pl boringssl-static clean package"
+
+  build-fips:
+    <<: *common
+    command: /bin/bash -cl "./mvnw -Pfips-boringssl-static -am -pl boringssl-static clean package"
+
+  shell:
+    <<: *common
+    volumes:
+      - ~/.m2/repository:/root/.m2/repository
+      - ~/.gitconfig:/root/.gitconfig:delegated
+      - ~/.gitignore:/root/.gitignore:delegated
+      - ..:/code:delegated
+    entrypoint: /bin/bash

docs/musl-compatibility.md

@@ -224,6 +224,14 @@ The check must go further than loading. Minimum bar, in order of strength:
 
 Only (3) would catch a library that loads but whose crypto is broken.
 
+In CI this is the `musl-verify` job. It runs against the CentOS 6 and CentOS 7 release jars on
+several Alpine variants, and, bare x86_64 only, against the two Debian 13 jars: the
+default-profile one and the **FIPS** one (`debian13-x86_64-fips`, see `docker/Dockerfile.debian13`).
+The FIPS leg is the one with no substitute: its power-on self-test and integrity check run in an
+ELF constructor during `dlopen`, so only a real load shows that the post-link `patchelf` left the
+module intact. Before that leg existed the FIPS profile was built by nobody but downstream users,
+and a change made to the release profiles and not ported to it surfaced only there.
+
 Two TLS 1.3 behaviours will make a naive handshake test report false failures:
 - the client reaches `NOT_HANDSHAKING` while the server still sits in `NEED_UNWRAP` waiting
   for optional post-handshake traffic — treat an idle `NEED_UNWRAP` as settled;