[dwoz]

Summary

• CPython 3.14.10 shipped a bad backport of upstream gh-149816 (CPython PR #160006, merged 2026-10-21). The main-branch fix landed as `int fips = !disable_fips_property(py_ht);` in `Modules/_hashopenssl.c::py_digest_by_name`, but the 3.14 backport dropped the leading `!`, inverting the FIPS property polarity.
• Under FIPS, `_hashlib.openssl_md5(usedforsecurity=False)` now fetches MD5 without the `-fips` property filter, so OpenSSL can't find a non-FIPS MD5 and the probe raises. `hashlib.py`'s dispatch then falls back to the builtin `_md5` (compiled in via `--with-builtin-hashlib-hashes=blake2,md5,sha1,sha2,sha3` in `relenv/build/linux.py:596`), which has no FIPS awareness and silently returns an MD5 digest. Conversely, `openssl_md5(usedforsecurity=True)` fetches with `-fips` and succeeds via a non-FIPS provider — a silent FIPS bypass.
• Caught by `Test FIPS compatability (3.14, x86_64)` on PR Release 0.22.32 #338 after the Python 3.14.9 → 3.14.10 bump; 3.10–3.13 and 3.14.9 pass, 3.14.10 fails.
• Apply the one-character upstream fix as a build-time patch across linux/darwin/windows. The regex matches the broken form only — a correctly-fixed source has `!disable_fips_property` and the regex won't match, so this is idempotent and self-disabling. Remove once a 3.14 point release ships the real fix.

Refs

• CPython main fix: python/cpython@23469818538c
• 3.14 bad backport: [3.14] gh-149816: fix a race when fetching OpenSSL digests (GH-153019) python/cpython#160006
• Failing CI job on PR Release 0.22.32 #338: https://github.com/saltstack/relenv/actions/runs/41381368304/job/125137697696

Test plan

• CI: `Test FIPS compatability (3.14, x86_64)` turns green
• CI: `Test FIPS compatability (3.10 / 3.11 / 3.12 / 3.13, x86_64)` stay green (regex is no-op on sources that don't contain the broken form)
• CI: all other 3.14 build+verify jobs stay green (patch is a one-character addition to a single pre-build source file; shouldn't affect anything else)