gh-84559: multiprocessing: detect if forkserver cannot work due to missing hmac-sha256 by gpshead · Pull Request #127467 · python/cpython (original) (raw)

This is a with a dumb "openssl fips mode" config that blocks all ciphers, running a python also configured not to have a fallback builtin sha256 module. configure --without-builtin-hashlib-hashes, and set the OPENSSL_CONF= environment variable to point to a file like https://github.com/python/cpython/blob/905ba7f06c12f7ef9985ccaa2bf24229f759a2e1/Lib/test/hashlibdata/openssl.cnf and you can repro this kind of setup.

this is primarily a "get the test suite to work in this situation" as we have a buildbot running with that type of config to better understand odd config failure modes.

i don't expect anyone to actually run their system with such a borked config. I'm not spending a lot of time on this, but I do consider it a "nice to have" for the redistributors who make strange "fips mode" envrionments for customers. they should wind up with less pain this way. Even though it isn't how any CPython binary release we ship would ever be configured. ie, it should unblock #127298.

Ack, whilst SHA-2 is still valid for post-2035 as per https://csrc.nist.gov/pubs/ir/8547/ipd it could be the case that people move on to just SHA-3 & SHAKE, at which point SHA-2 hmac may become irrelevant in favour of KMAC-256. And these changes will make things limp along.

For pre-2035 horizon, the relevant changes that we do need from this pr is the test/ changes and the multiprocessing is nice-to-have (or borderline theoretical / making it easier to reason about by using absolutely crypto-less config AKA zero-knowledge as to what future holds).

So can this be marked not-draft? what is missing to land the testsuite changes of this PR, or even this whole PR to unblock #127298?