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

Motivation:

CI builds boringssl-static only on the two release images and never builds the
FIPS profile. #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, services `build`
  and `build-fips`. Every input is pinned: base image by digest, Debian
  archive by snapshot.debian.org timestamp, clang by version, Go by version
  and checksum (BoringSSL's go.mod is ahead of trixie's Go). trixie has no
  JDK 8, so 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,
  plus bare-Alpine musl-verify legs on their jars. The FIPS module's integrity
  check runs in an ELF constructor at dlopen, so only a real load proves the
  post-link patchelf left it intact.

Result:

A change to the FIPS profile, or one to the release profiles that is not
ported to it, fails on the PR. Not a release image: 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; 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 }}
     permissions:
@@ -219,6 +229,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; 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 }}
     permissions:
@@ -280,6 +290,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,81 @@
+# Everything in this image is pinned: the base by digest, the Debian archive by a
+# snapshot.debian.org timestamp, clang by version, Go by version and checksum. To refresh it,
+# bump the four values below together and rebuild.
+ARG debian_image=debian:13.7@sha256:9cc080028c43b27d2074d63a5f9caf7166d731494965616c1a6d2827a004585c
+FROM $debian_image
+ARG debian_snapshot=20260915T000000Z
+ARG clang_version=19
+ARG go_version=1.27.1
+ARG go_sha256_amd64=63d339f0da5ab53635a56f2490a7984dfe12dfcff22ad749f63edaf590168445
+ARG go_sha256_arm64=3450b45a3f9ee8568792736a5c5e70a1f2e9b36c35a8f74958c03e51d7d92bec
+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, which compiles BoringSSL with clang. Google's FIPS.md asks for
+# recent stable Clang, Go, Ninja and CMake: clang, ninja and cmake are Debian 13's own. Go is
+# not: BoringSSL's go.mod floor (1.25.8 on the pinned fips-20260721) is ahead of trixie's 1.24,
+# so it comes from go.dev, checksum-verified. 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.34 floor.
+# It exists to give the boringssl-static and FIPS builds CI coverage on a current toolchain.
+
+# Freeze the archive. snapshot.debian.org serves the archive as it was at that instant, so the
+# same package versions install no matter when the image is built; Valid-Until has long passed
+# by then, hence check-valid-until=no.
+RUN rm -f /etc/apt/sources.list.d/debian.sources \
+ && echo "deb [check-valid-until=no] http://snapshot.debian.org/archive/debian/$debian_snapshot trixie main" > /etc/apt/sources.list \
+ && echo "deb [check-valid-until=no] http://snapshot.debian.org/archive/debian/$debian_snapshot trixie-updates main" >> /etc/apt/sources.list \
+ && echo "deb [check-valid-until=no] http://snapshot.debian.org/archive/debian-security/$debian_snapshot trixie-security main" >> /etc/apt/sources.list
+
+RUN apt-get update && apt-get install -y --no-install-recommends \
+ autoconf \
+ automake \
+ bzip2 \
+ ca-certificates \
+ clang-$clang_version \
+ cmake \
+ 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/* \
+ && ln -s clang-$clang_version /usr/bin/clang && ln -s clang++-$clang_version /usr/bin/clang++
+
+# dpkg's amd64/arm64 spelling matches go.dev's and the JVM directory name.
+RUN ARCH=$(dpkg --print-architecture) \
+ && case $ARCH in amd64) GO_SHA256=$go_sha256_amd64;; arm64) GO_SHA256=$go_sha256_arm64;; esac \
+ && wget -q https://go.dev/dl/go$go_version.linux-$ARCH.tar.gz \
+ && echo "$GO_SHA256  go$go_version.linux-$ARCH.tar.gz" | sha256sum -c - \
+ && tar -C /opt -xzf go$go_version.linux-$ARCH.tar.gz && rm go$go_version.linux-$ARCH.tar.gz \
+ && ln -s /opt/go/bin/go /usr/local/bin/go && ln -s /opt/go/bin/gofmt /usr/local/bin/gofmt \
+ && ln -s /usr/lib/jvm/java-21-openjdk-$ARCH /usr/lib/jvm/java-21 \
+ && go version && clang --version | head -1 && ninja --version && cmake --version | head -1
+ENV JAVA_HOME /usr/lib/jvm/java-21
+# Use exactly the pinned Go; never let it fetch another toolchain.
+ENV GOTOOLCHAIN local
+
+# /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,19 @@ 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, which compiles BoringSSL with clang. Everything is pinned: the
+base image by digest, the Debian archive by a snapshot.debian.org timestamp, clang by version,
+Go by version and checksum. 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,46 @@
+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
+# 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
+      cache_from:
+        - type=registry,ref=ghcr.io/netty/netty-tcnative-build-cache:debian13
+      cache_to:
+        - type=registry,ref=ghcr.io/netty/netty-tcnative-build-cache:debian13,mode=max,ignore-error=true
+
+  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

@@ -223,6 +223,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;