Running test_hashlib, test_hmac, test_ssl with OPENSSL_FORCE_FIPS_MODE=1 on CI?

In response to https://www.cve.org/CVERecord?id=CVE-2026-119170 and how the regression was introduced in [3.14] gh-149816: fix a race when fetching OpenSSL digests (GH-153019) by picnixz · Pull Request #160006 · python/cpython · GitHub and only discovered post merge, I wonder if we could add this to a CI job that already uses OpenSSL:

OPENSSL_FORCE_FIPS_MODE=1 python -m test ... test_hashlib test_hmac test_ssl

The tests take ~15 seconds on my machine when run without parallelization (-jN).

TIL about this flag. Until today I always had two OpenSSL builds, one with a special FIPS configuration and one without, mainly to exercise the fallbacks and so on, in addition to build bots. Usually I check the buildbots outputs but since it was during the sprint, I was likely too tired and hence introduced that regression.

That being said, I think we can add a single job that just runs some SSL-related tests with that environment.

1 Like

@hroncok Do you want to send an issue/PR for that one? or should I do it myself?

I was waiting for more feedback, but happy to do it. Do you have some tip on which would be the best file to add it to? cpython/.github/workflows at main · python/cpython · GitHub is a lot to digest.

Likely around cpython/.github/workflows/build.yml at main · python/cpython · GitHub. Those tests are for the SSL-only tests.

1 Like

Perhaps it could be wired into Tools/ssl/multissltests.py and added to the matrix in the workflow that runs it?

2 Likes

We do have some CentOS FIPS buildbots:

  • AMD64 CentOS10 FIPS No Builtin Hashes 3.x: Buildbot
  • AMD64 CentOS10 FIPS Only Blake2 Builtin Hash 3.x: Buildbot
  • AMD64 CentOS9 FIPS No Builtin Hashes 3.x: Buildbot
  • AMD64 CentOS9 FIPS Only Blake2 Builtin Hash 3.x: Buildbot

And similar buildbot for stable versions. The problem is that the 3.14 and 3.15 jobs are red (fail) for a long time and so don’t report new regressions since tests were already failing :frowning:

Adding new jobs on GitHub sounds like a good idea! Especially if we can only run them when “ssl code” is modified (GitHub Action already implements this logic for “SSL” jobs", we can reuse it).

Some collateral issues first, starting with ValueError: [Provider routines] invalid salt length in test_hashlibtest_pbkdf2_hmac_c on FIPS w/ OpenSSL 4.0.3 · Issue #161739 · python/cpython · GitHub

Fun fact, it’s Fedora/RHEL only :person_facepalming: