Repository navigation
fix: preserve musl compatibility in FIPS build - #1008
Merged
normanmaurer merged 1 commit intoSep 9, 2026
Merged
Conversation
pe-bernard
marked this pull request as ready for review
September 8, 2026 10:16
pe-bernard
force-pushed
the
pe-bernard/fix-fips-musl-compatibility
branch
from
September 8, 2026 10:18
e1e0f73 to
7972ff2
Compare
Member
|
/cc @fredericgermain |
Contributor
|
Ah a FIPS variant. I didn't see that one. I'm testing FIPS in CI in many variants rn, using the pinned fips commit in https://boringssl.googlesource.com/boringssl. There could be quite a lot of subtilities with FIPS and compiler flags. That's something you'd be interested to have in CI? It could be part of work I did on the CI builds, but it'd need some time to finalise. Thanks Pierre-Eloi for your PR! |
fredericgermain
added a commit
to fredericgermain/netty-tcnative
that referenced
this pull request
Sep 9, 2026
…both jars on Alpine Motivation: CI built boringssl-static only on the two release images and never built the FIPS profile at all, so netty#997 could add the musl check to that profile without the matching link changes and nothing failed until a downstream build did (netty#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.
fredericgermain
added a commit
to fredericgermain/netty-tcnative
that referenced
this pull request
Sep 9, 2026
…both jars on Alpine Motivation: CI built boringssl-static only on the two release images and never built the FIPS profile at all, so netty#997 could add the musl check to that profile without the matching link changes and nothing failed until a downstream build did (netty#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.
fredericgermain
added a commit
to fredericgermain/netty-tcnative
that referenced
this pull request
Sep 19, 2026
…both jars on Alpine Motivation: CI built boringssl-static only on the two release images and never built the FIPS profile at all, so netty#997 could add the musl check to that profile without the matching link changes and nothing failed until a downstream build did (netty#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.
fredericgermain
added a commit
to fredericgermain/netty-tcnative
that referenced
this pull request
Sep 23, 2026
…both jars on Alpine Motivation: CI builds boringssl-static only on the two release images and never builds the FIPS profile. netty#997 could add the musl check to that profile without the matching link changes, and nothing failed until a downstream build did (netty#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.
fredericgermain
added a commit
to fredericgermain/netty-tcnative
that referenced
this pull request
Oct 2, 2026
…both jars on Alpine Motivation: CI builds boringssl-static only on the two release images and never builds the FIPS profile. netty#997 could add the musl check to that profile without the matching link changes, and nothing failed until a downstream build did (netty#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.
fredericgermain
added a commit
to fredericgermain/netty-tcnative
that referenced
this pull request
Oct 2, 2026
…both jars on Alpine Motivation: CI builds boringssl-static only on the two release images and never builds the FIPS profile. netty#997 could add the musl check to that profile without the matching link changes, and nothing failed until a downstream build did (netty#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: its artifacts need a newer glibc than the release ones.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
#997 added the musl compatibility check to the FIPS
native-jarexecution, but did not port the corresponding link and post-link handling from the Linux release profiles. As a result, FIPS artifacts retain glibc loader and runtime dependencies that make them fail the new check.Changes
fips-boringssl-staticld-linuxDT_NEEDEDentry from the final FIPS native library before the musl checkVerification
xmllint --noout boringssl-static/pom.xmlgit diff --checkLocal Maven model validation was not run because this machine has no Java runtime.