Update OpenSSL versions for CI and Windows · Issue #131423 · python/cpython · GitHub

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:

Update https://github.com/python/cpython-source-deps to pull OpenSSL 3.0.16 (cc @zooba)
Update macOS and Windows builds to use OpenSSL 3.0.16.
Update CI workflows to test against [3.0.16, 3.1.8, 3.2.4, 3.3.3, 3.4.1]
Update OpenSSL data headers

Linked PRs

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.

The openssl-bin-3.0.16 tag is now available for integrating into the Windows build.

The 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:

OpenSSL 1.1.1 is the minimum version and OpenSSL 3.0.9 is the recommended minimum version for the ssl and hashlib extension modules.

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:

1.1.1z* releases are security backports by a third-party:

https://github.com/kzalewski/openssl-1.1.1/releases

pythongh-131423: Update macOS installer to use OpenSSL 3.0.16. (pytho…

[3.13] gh-131423: Update macOS installer to use OpenSSL 3.0.16. (GH-1…

[3.12] gh-131423: Update macOS installer to use OpenSSL 3.0.16. (GH-1…

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.

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.

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.

OK, I've logged #132339 specifically for supporting OpenSSL 3.5.

gh-131423: Update OpenSSL data to 3.4.1 on Linux (#131618)

I won't backport my recent change because we didn't do this when we updated to 3.4 in #127330.

gh-131423: update note in `Tools/ssl/make_ssl_data.py` (#133077)

>>> 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_sigalgs and 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.

Update OpenSSL versions for CI and Windows · Issue #131423 · python/cpython · GitHub

Repository navigation

Update OpenSSL versions for CI and Windows #131423

Plan:

Linked PRs

27 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Update OpenSSL versions for CI and Windows · Issue #131423 · python/cpython · GitHub

Repository navigation

Update OpenSSL versions for CI and Windows #131423

Description

Plan:

Linked PRs

Activity

zooba commented on Mar 18, 2025

picnixz commented on Mar 18, 2025

zooba commented on Mar 18, 2025

zooba commented on Mar 18, 2025

picnixz commented on Mar 18, 2025

hugovk commented on Mar 22, 2025

picnixz commented on Mar 22, 2025

hugovk commented on Mar 22, 2025

27 remaining items

scw commented on Apr 9, 2025

zooba commented on Apr 9, 2025

ned-deily commented on Apr 9, 2025

scw commented on Apr 10, 2025

picnixz commented on Apr 25, 2025

typenoob commented on Oct 29, 2025

picnixz commented on Oct 29, 2025

zooba commented on Oct 29, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions