The FIPS branches of AWS-LC were covered by the VTest matrix, but only
built in non-FIPS mode: nothing exercised the FIPS-specific code paths in
HAProxy, in particular the compliance checks in src/fips.c which reject
non-approved ciphers, curves, signature algorithms and TLS versions at
configuration time. A regression there is invisible until someone builds
HAProxy against an AWS-LC FIPS library.
Add a nightly workflow that builds AWS-LC with FIPS=1 and runs the VTest
and unit test suites against it, in the same way the other SSL library
workflows do. It tests three sources, resolved through
determine_aws_lc():
- AWS-LC 3.x, the fips-2024-09-27 branch;
- AWS-LC 4.x, the fips-2025-09-12-lts branch;
- the latest AWS-LC release tag, whose FIPS module is the one currently
submitted for validation, so that the newest code is covered too
instead of only the two maintenance branches.
Branch specs resolve to the head commit of the branch, which is passed as
AWS_LC_VERSION and downloaded as an immutable archive by build-ssl.sh, so
a run is reproducible and the build cache is only renewed when the branch
advances. The resolved release and commit are both part of the cache
key, matching the version-specific identity used by the VTest job so the
two workflows never share a half-populated cache entry.
The workflow only runs on the upstream repository, or on manual dispatch
from a fork, like the other SSL library workflows.
Note that the AWS-LC latest release is not expected to be identical to
either FIPS branch; it is built in FIPS mode for its own FIPS module
version, which is what the extra job is meant to detect early.