Repository navigation
Update OpenSSL versions for CI and Windows #131423
Description
Activity
Any reason we shouldn't move the Windows release forward to a newer version than 3.0 (for 3.14, that is - prior releases presumably stay where they are)?
Any reason we shouldn't move the Windows release forward to a newer version than 3.0 (for 3.14, that is - prior releases presumably stay where they are)?
I don't know. I guess we don't need the features added in 3.1. However, from a performance perspective, OpenSSL 3.0 seems to be way much slower compared to OpenSSL 3.1 on Windows builds: https://openssl-library.org/performance.html. However, OpenSSL 3.0 is the "LTS" version of OpenSSL so for Windows it may be better (see https://openssl-library.org/policies/releasestrat/index.html).
Now, in 2026, 3.0 would no more be LTS, so we might jump to the next LTS at that moment. WDYT? Otherwise, if there's no more LTS for OpenSSL, we might need to update Python much more frequently once a version becomes out-of-date (non-LTS releases are supported for 2 years, so I don't know how you want to proceed)
Hmm... yeah... let's stick to their LTS releases then. Presumably they'll have to nominate another LTS release before the current one expires, though it's a bit unfortunate we can't count on any to be supported for the same time as our own release.
Reacted by Gregory P. SmithThe
openssl-bin-3.0.16tag is now available for integrating into the Windows build.Reacted by Bénédikt Tran and Gregory P. SmithReacted by Bénédikt TranThe openssl-bin-3.0.16 tag is now available for integrating into the Windows build.
Thanks! I'm sorry but I won't be able to update this until Sunday as I'm going offline for a few days.
https://docs.python.org/3/using/configure.html says:
Shall we bump that 3.0.9 to 3.0.16?
non-LTS releases are supported for 2 years, so I don't know how you want to proceed
3.1 just went EOL on 2025-03-14, and 1.1.1 has been EOL since 2023-09-11.
Presumably they'll have to nominate another LTS release before the current one expires, though it's a bit unfortunate we can't count on any to be supported for the same time as our own release.
Yes, 3.5 (due for release next month, 2025-04-08) will be the next LTS:
https://openssl-library.org/post/2025-02-20-openssl-3.5-lts/
And:
In addition, the OpenSSL Corporation and Foundation have agreed to designate an LTS every two years. That means there will be an LTS release in April of 2027, another in 2029, and so on. As always, each LTS will be supported for 5 years with the final year’s support being security patches only.
...
Predictable LTS releases should help projects that depend on them plan their own development schedules. There will always be at least two supported LTS releases of OpenSSL in addition to predictably timed regular releases.What is our policy around dropping EOL OpenSSL? Given there will always be two LTS, can we go as far as only supporting those?
1.1.1 has been EOL but I don't know about 1.1.1z for instance. It's still receiving updates I think and our build requirements are 1.1.1 at least. I'm not at home yet so I can't check it precisely but I'll investigate this evening of tomorrow
1.1.1w was the last official 1.1.1 from OpenSSL:
- https://openssl-library.org/news/openssl-1.1.1-notes/
- https://github.com/openssl/openssl/releases
- https://openssl-library.org/policies/releasestrat/index.html
1.1.1z* releases are security backports by a third-party:
27 remaining items
OpenSSL 3.5.0 has been released, which is great as it is an LTS release 🎉 . They've also formalized the release schedule over a longer time period on their roadmap.
Does adding OpenSSL 3.5.0 support make sense in the context of this issue, or should I log something new?
Start a new issue. I would expect there to be more changes than simply adding the version to the build, and it may require more discussion.
Reacted by Shaun WalbridgeStart a new issue. I would expect there to be more changes than simply adding the version to the build, and it may require more discussion.
Yes, and since there's more than a year overlap between the two LTS versions and since 3.5.x was just released, we would probably not want to immediately switch from 3.0.x to 3.5.x.
- added a commit that references this issue
on Apr 25, 2025 >>> import ssl >>> ssl.get_sigalgs() Traceback (most recent call last): File "<python-input-1>", line 1, in <module> ssl.get_sigalgs() ~~~~~~~~~~~~~~~^^ NotImplementedError: Getting signature algorithms requires OpenSSL 3.4 or later.
Shall we update window's versions to 3.4 in order to use
get_sigalgsand functions this pr #138269 add?Well we coule even update it to 3.5 if it is possible as it is the next LTS?
We want to stick to LTS releases for our Windows distributions (it should be possible to build with 3.4 if you have your own OpenSSL 3.4 build available, but we do this to limit our maintenance burden). Other distributors can use 3.4 if they want.
If 3.5 is ready for us to adopt, then we are probably already thinking about it. I haven't been involved there, though.
OpenSSL v3.4.1 is out and contains some security patches (see https://github.com/openssl/openssl/releases/tag/openssl-3.4.1). There is one high vulnerabilty (CVE-2024-12797) that was fixed.
However, what I'm interested in, are the fixes that allow me to continue working on #128391 (see openssl/openssl#26388). Note that this high vulnerability does not affect the Windows build as the latter is still using OpenSSL 3.0.15 which is only affected by the following low vulnerabilities:
Those low vulnerabilities affect OpenSSL 1.1.1+ and 3.x versions that we currently use and were fixed in the February 2025 release.
Note: I don't think Python is directly affected by the low vulnerabilies and I just want the fixes that were included in those releases for my own work. Since the high vulnerability only affects 3.2+, Windows builds should not be affected.
cc @gpshead
Plan:
Linked PRs
Tools/ssl/make_ssl_data.py#133077