Repository navigation
[3.14] gh-149816: fix a race when fetching OpenSSL digests (GH-153019) - #160006
Conversation
…honGH-153019) (cherry picked from commit 2346981) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
|
!buildbot FIPS |
|
🤖 New build scheduled with the buildbot fleet by @picnixz for commit ceba61d 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F160006%2Fmerge The command will test the builders whose names match following regular expression: The builders matched are:
|
| state->hashtable, (const void*)name | ||
| ); | ||
| py_hashentry_t *entry = _Py_hashtable_get(state->hashtable, name); | ||
| int fips = disable_fips_property(py_ht); |
There was a problem hiding this comment.
Other branches have:
| int fips = disable_fips_property(py_ht); | |
| int fips = !disable_fips_property(py_ht); |
This leads to the following regression when comparing 3.14.8 with 3.14.10:
import _hashlib
print("FIPS mode active:", bool(_hashlib.get_fips_mode()))
for usedforsecurity in (True, False):
try:
_hashlib.openssl_md5(usedforsecurity=usedforsecurity)
print(f"usedforsecurity={usedforsecurity:5} -> ALLOWED")
except ValueError as e:
print(f"usedforsecurity={usedforsecurity:5} -> BLOCKED ({e})")3.14.8 (correct):
usedforsecurity=True -> BLOCKED ([digital envelope routines] unsupported)
usedforsecurity=False -> ALLOWED (md5 object constructed)
3.14.10 (broken):
usedforsecurity=True -> ALLOWED (md5 object constructed)
usedforsecurity=False -> BLOCKED ([digital envelope routines] unsupported)
There was a problem hiding this comment.
Yes, it's known. I flipped it by mistake :(
There was a problem hiding this comment.
I commented here first, then looked for a fix before I send it and I found one. Sorry for the noise.
There was a problem hiding this comment.
no worry, it's me that is sorry the issue!
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: * ``openssl_md5(usedforsecurity=False)`` under FIPS 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``), which has no FIPS awareness and silently returns an MD5 digest. * Conversely, ``openssl_md5(usedforsecurity=True)`` would fetch with the ``-fips`` filter and succeed in FIPS mode via a non-FIPS provider, silently bypassing FIPS enforcement. Caught by ``Test FIPS compatability (3.14, x86_64)`` on PR #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 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: python/cpython#160006
(cherry picked from commit 2346981)