gh-135261: bring back CI job for testing OpenSSL 1.1.1w #135262
Conversation
|
Ok, everything looks good. I'll let a code owner merge this one (I don't need it immediately, but it can ease my life later on) |
|
FTR, this PR would effectively revert #123701 from nine months ago. Do we want to do that? |
|
I do want it because we have code that is conditioned to OpenSSL version. And the (official) build requirements are still 1.1.1w so it makes sense to test this. Otherwise I don't know when we test those paths. |
|
cc @zware |
|
See my comment on the issue: in short, we should update the build requirements docs and not provide free support for something that the OpenSSL project charges lots of money for. @gpshead, any opinions on this? |
|
If we do agree to update the build requirements doc, we should also update the OpenSSL version test in |
|
I really want to add this job because it's tiring for me to re-configure my local Python to switch between the two implementations. Because we now support AWS-LC in the CI which has 1.1.1-like API and because we still have non-dead code with OpenSSL 1.1.1, I will merge this one next week. If we decide to drop 1.1.1, then we should really be careful because I don't think it makes sense to say that we drop the support but we still have code expecting to work. The matter of OpenSSL is not only about the SSL module. It's also about the hashlib module which still relies on OpenSSL 1.1.1 functions for HMAC (I'm currently adding support for OpenSSL 3.x). I don't know if AWS-LC supports EVP interface for HMAC though and whether it's detected as a OpenSSL 3.x or OpenSSL 1.1.1. In the SSL module, we are still using APIs that were deprecated in OpenSSL 1.1.0 such as TLS 1.1 & 1.2. However, there is no removal plan for supporting those protocols (there's only a deprecation warning). So removing 1.1.1 support also means removing support for deprecated protocols in one go, which can't be achieved before Python 3.17 at the earliest (but I would recommend at least a 5-years deprecation period, or maybe only a soft deprecation). |
|
Does the rationale from the issue re upstream EOL still apply? |
Well.. it depends. I agree that OpenSSL 1.1.1 is EOL and we shouldn't support something that is EOL. However, it's actually more than just supporting. OpenSSL 3.x has functions that are deprecated since OpenSSL 1.1.1 and but we still use the following guard: #ifndef OPENSSL_API_COMPAT
// 0x10101000L == 1.1.1, 30000 == 3.0.0
#define OPENSSL_API_COMPAT 0x10101000L
#endifIOW, we ask OpenSSL 3.x to expose those functions as being stable and not deprecated. Now, at runtime, if the user has OpenSSL 3.x, then it will directly use the OpenSSL 3.x bindings. In the current code of hashlib and ssl, we use functions that are both present in OpenSSL 1.1.1 and OpenSSL 3.x, and those functions are either stable or deprecated depending on the bindings. For the OpenSSL 3.x user, it's as if they are using OpenSSL 1.1.1. But for an OpenSSL 1.1.1 user, they are using a stable version for them. Let's say we drop 1.1.1 support because it's EOL. This means switching all 1.1.1-like API calls to 3.x API calls. Unfortunately those are not necessarily straightforward (as shown for the HMAC PR). For SSL, it's even worse as we have many more functions that are deprecated in 3.x (like TLS 1.2). We need to switch to I don't think it makes sense to actually use deprecated functions ourselves but require people to upgrade their OpenSSL version. We would still not use the new API. And code where we have conditional checks depending on the OpenSSL version either need to be removed entirely (but I don't think we can just drop OpenSSL 1.1.1 support in Python 3.15, I'd like to give sufficient time to downstream users), or they should be tested until wew decide to remove them (that's my point: test any code that can be executed at runtime, until it's removed). |
|
Personally, I would be very happy if I could assume that the underlying OpenSSL library is 3.x and later. Unforunately, that's not the case, so I need a way to test my code for all users that could not necessarily be using 3.x. We can always remove the job once all requirements have been bumped but I would advise against bumping requirements while retaining code that assume a lower version. I think it's preferrable that we have two implementations at one time (with ifdef guards) and once it's migrated and tested, we can bump it and remove dead code (so that we don't use deprecated features) |
|
Thanks @picnixz for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
…GH-135262) This partially reverts commit d83e30c by bringing back the CI job for testing OpenSSL 1.1.1w. Despite this version being upstream EOL, the rationale for keeping it as follows: - It most resembles other 1.1.1-work-a-like ssl APIs supported by important vendors. - Python officially requires OpenSSL 1.1.1 or later, although OpenSSL 3.0 or later is recommended for cryptographic modules. Since changing the build requirements requires a transition period, we need to keep testing the allowed versions. - The code base still contains calls to OpenSSL functions that are deprecated since OpenSSL 3.0 as well as `ifdef` blocks constrained to OpenSSL 1.1.1. (cherry picked from commit 96b7a2e) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
|
Sorry, @picnixz, I could not cleanly backport this to |
|
GH-138109 is a backport of this pull request to the 3.14 branch. |
…ythonGH-135262) This partially reverts commit d83e30c by bringing back the CI job for testing OpenSSL 1.1.1w. Despite this version being upstream EOL, the rationale for keeping it as follows: - It most resembles other 1.1.1-work-a-like ssl APIs supported by important vendors. - Python officially requires OpenSSL 1.1.1 or later, although OpenSSL 3.0 or later is recommended for cryptographic modules. Since changing the build requirements requires a transition period, we need to keep testing the allowed versions. - The code base still contains calls to OpenSSL functions that are deprecated since OpenSSL 3.0 as well as `ifdef` blocks constrained to OpenSSL 1.1.1. (cherry picked from commit 96b7a2e) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
|
GH-138110 is a backport of this pull request to the 3.13 branch. |
…ythonGH-135262) This partially reverts commit ad944b5 by bringing back the CI job for testing OpenSSL 1.1.1w. Despite this version being upstream EOL, the rationale for keeping it as follows: - It most resembles other 1.1.1-work-a-like ssl APIs supported by important vendors. - Python officially requires OpenSSL 1.1.1 or later, although OpenSSL 3.0 or later is recommended for cryptographic modules. Since changing the build requirements requires a transition period, we need to keep testing the allowed versions. - The code base still contains calls to OpenSSL functions that are deprecated since OpenSSL 3.0 as well as `ifdef` blocks constrained to OpenSSL 1.1.1. (cherry picked from commit 96b7a2e)
…GH-135262) This partially reverts commit d83e30c by bringing back the CI job for testing OpenSSL 1.1.1w. Despite this version being upstream EOL, the rationale for keeping it as follows: - It most resembles other 1.1.1-work-a-like ssl APIs supported by important vendors. - Python officially requires OpenSSL 1.1.1 or later, although OpenSSL 3.0 or later is recommended for cryptographic modules. Since changing the build requirements requires a transition period, we need to keep testing the allowed versions. - The code base still contains calls to OpenSSL functions that are deprecated since OpenSSL 3.0 as well as `ifdef` blocks constrained to OpenSSL 1.1.1. (cherry picked from commit 96b7a2e) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
…5262) (#138110) This partially reverts commit ad944b5 by bringing back the CI job for testing OpenSSL 1.1.1w. Despite this version being upstream EOL, the rationale for keeping it as follows: - It most resembles other 1.1.1-work-a-like ssl APIs supported by important vendors. - Python officially requires OpenSSL 1.1.1 or later, although OpenSSL 3.0 or later is recommended for cryptographic modules. Since changing the build requirements requires a transition period, we need to keep testing the allowed versions. - The code base still contains calls to OpenSSL functions that are deprecated since OpenSSL 3.0 as well as `ifdef` blocks constrained to OpenSSL 1.1.1. (cherry picked from commit 96b7a2e)
…tuations docs: add news entry for TracebackException punctuation fix style: remove trailing whitespace in traceback.py Update 2025-08-24-11-42-38.gh-issue-137716.7-Mtj-.rst Update 2025-08-24-11-42-38.gh-issue-137716.7-Mtj-.rst refactor: improve suggestion message computation and punctuation handling style: remove trailing whitespace in traceback.py pythongh-137986: Fix and improve the csv functions docstrings (pythonGH-137987) The csv.register_dialect() docstring no longer imply that it returns a dialect. All functions have now signatures. Co-authored-by: maurycy <5383+maurycy@users.noreply.github.com> pythongh-135261: bring back CI job for testing OpenSSL 1.1.1w (python#135262) This partially reverts commit d83e30c by bringing back the CI job for testing OpenSSL 1.1.1w. Despite this version being upstream EOL, the rationale for keeping it as follows: - It most resembles other 1.1.1-work-a-like ssl APIs supported by important vendors. - Python officially requires OpenSSL 1.1.1 or later, although OpenSSL 3.0 or later is recommended for cryptographic modules. Since changing the build requirements requires a transition period, we need to keep testing the allowed versions. - The code base still contains calls to OpenSSL functions that are deprecated since OpenSSL 3.0 as well as `ifdef` blocks constrained to OpenSSL 1.1.1.
I don't think I need to regen the OpenSSL data here so I'll just check if the CI job works.