Description
The minimal required OpenSSL version is 1.1.1 but we recommend to use OpenSSL 3.x and later for hashlib and ssl. However, we still have many code paths that are conditioned to OpenSSL versions and those are not eagerly tested. I suggest adding an SSL CI job for OpenSSL 1.1.1.
Ideally, I'd like to backport such job up to 3.9, but I'm not sure if I'm allowed to do this as it's not really a security issue.
Activity
ned-deily commentedon Jun 8, 2025
FWIW, testing of 1.1.1 was deliberately removed in #123700 nine months ago.
picnixz commentedon Jun 8, 2025
I'll forward the comment I wrote on the PR here as well:
See https://docs.python.org/3/using/configure.html#build-requirements as well.
To be clear, the code paths that need to be tested are those in
_hashlib
, for instance:cpython/Modules/_hashopenssl.c
Lines 62 to 72 in 8d17a41
cpython/Modules/_hashopenssl.c
Lines 2086 to 2103 in 8d17a41
Also, some constructions are deprecated in OpenSSL 3.0 but are still used (the
HMAC_*
interface is deprecated, and we should useEVP_MAC
instead; this is #134531).ned-deily commentedon Jun 8, 2025
Considering that the OpenSSL project officially ended unpaid support for 1.1.1 in 2023, I think we should consider updating our build requirements docs to exclude 1.1.1 rather than reintroduce 1.1.1 support in testing. At the moment the OpenSSL project offers at considerable expense extended support contracts for 1.1.1 . There are also vendors who provide paid extended support contract for various versions of Python. We could leave that support to them for users who need it.
hugovk commentedon Jun 8, 2025
See also recent discussion in #131423.
picnixz commentedon Jun 8, 2025
One relevant comment was #131423 (comment). And I actually agreed with dropping 1.1.1 requirements. It's just that my system-wide installation is 1.1.1. It's not an issue for me to upgrade it.
The advantage of dropping 1.1.1 is that it simplifies a lot the code, both in
_hashopenssl.c
and in_ssl.c
. We can also drop the mnemonics from 1.1.1 that would be dead code. But I don't know about LibreSSL/BoringSSL that could be 1.1.1-ish. It's not officially supported, but it also doesn't cost much to keep it maintained for 1.1.1.However, whatever we choose, if we keep it some code path that only works for OpenSSL 1.1.1, we should somehow test it (because now, we don't test it at all)
gpshead commentedon Jun 10, 2025
@WillChilds-Klein may be able to provide CI or buildbot setup to help us maintain AWS-LC shaped support (per the discuss thread).
WillChilds-Klein commentedon Jul 3, 2025
PR for AWS-LC testing in CI is here. AWS-LC's
libssl
"looks like" OpenSSL 1.1.1'slibssl
, but we can't provide any strong compatibility guarantees there through time, neither for API nor ABI (particularly not ABI). If OpenSSL 1.1.1 is a meaningful target, it should be tested independently. But, I hope and expect that OpenSSL users will migrate to OpenSSL 3.x as OpenSSL resolves performance gaps between 1.1.x and 3.x.