FIPS-compliant build chain for boringssl in Bazel Registry (bzlmod)

[phlax]

Objective

Initiate design, tracking, and implementation of a FIPS-compliant boringssl build chain for the toolshed Bazel Registry (with support for bzlmod),

Security/Compliance Considerations

• FedRAMP guidance now mandates "latest stable versions" of toolchain (esp. llvm/clang/cmake/go/ninja), not legacy/pinned versions
• Build-time validation (including post-build tests) for FIPS, as required for compliance—not optional, and must be enforced before libs are exported
• First-class support for FIPS self-test results: Users must never be able to consume an unvalidated binary
• Isolation from MVS: All FIPS-relevant build tools/deps (e.g., go-fips, cmake/ninja versions) must be out-of-band from Bazel MVS to prevent accidental version drift/capture. go-fips is critical for this; for cmake/ninja, use rules_foreign_cc toolchain registration, not as separate modules
• BCR naming conventions: Use kebab-case for all new modules (e.g., boringssl-fips, go-fips) for clarity and searchability

Technical Plan

1. Module Chain (BCR)

• boringssl-fips: main entrypoint; depends on rules_foreign_cc and go-fips
• go-fips: supplies a FIPS-pinned Go runtime for validation tests, kept outside MVS
  • Needed because boringssl's FIPS validation logic is written in Go and run at build/test time
  • Other FIPS tools (cmake/ninja) handled via rules_foreign_cc toolchain registration, not as separate modules - as these are registered via foreign_cc they are already outside of MVS
• Toolchain/LLVM: keep as dev_dependency; document compliance principle, but don't force consumers to upgrade yet

2. Build Process

• Use cmake() from rules_foreign_cc with -DFIPS=1 for FIPS build
• Self-test/validation as a post-processing step, required before export
• Only validated build artifacts should be visible/usable to downstream consumers
  • All intermediate/non-validated build outputs MUST be private/inaccessible
  • Final targets (ssl, crypto, etc.) must depend on successful validation
• A build/test chain like:
  1. Private: Build libs via cmake (cmake() rule)
  2. Private: Validation step (genrule or sh_test) runs FIPS self-tests; only exposes libcrypto.a/libssl.a if passing
  3. Public: ssl, crypto CC library targets export validated libs

3. Naming/Structure

• boringssl-fips should be a standalone module (not built on top of boringssl), to avoid MVS entanglement
• Document clear separation between FIPS/non-FIPS (consumer opts-in by specifying bazel_dep(name = "boringssl-fips", ...))

4. Other Considerations

• Agent/owner should not take shortcuts: Security implications mean this chain must block unvalidated output as rigorously as possible
• Foreign_cc as build solution: All cmake/ninja build logic now should use standardized, explicit toolchains, not ad-hoc shell/genrules
• Continuous validation: As upstream FIPS rules/requirements evolve, registry should track toolchain changes and update the build/test chain accordingly

note: MVS is bzlmods "minimum version system" - for the fips build we need to take the build chain out of that in case a depedency specifies "latest unstable" or any version that resolves as non-fips-compliant

[phlax]

cc @ggreenway this is a summary of my investigations into how to best shift the fips build into bzlmod

there are some related concerns around versions (eg our current llvm version may not actually be compliant)

and there is a concern over propagation (ie ensuring all our upstreams use the fips build) - which is slightly changed when moving to bzlmod (see eg grpc/grpc#41437)

to summarize (further) the immediate plan

• create boringssl-fips and go-fips to ensure these are taken out of MVS and version is tightly controlled
• use foreign_cc - we can enforce cmake/ninja versions via foreign_cc which means we dont need to worry about MVS and simplifies the build

[phlax]

one question im wondering - why not just make our build always use the fips boringssl?

i have a feeling this may have been suggested elsewhere - but it would be one less dep to worry about