Pathway to requiring OpenSSL 3 or newer in CPython?

Hi all,

I’m opening this up for discussion – originally I was thinking to propose a pre-PEP here, but I realized that I don’t know enough about LTS distros to confidently state that OpenSSL 3 is widely adopted :slightly_smiling_face:

Context: OpenSSL 1.1.1 is EOL, and has been EOL since September 2023. As such, there are no (official, public) maintained releases of OpenSSL 1.1.1 anymore, all development is on 3.0 or newer.

Last time around, PEP 644 helped define the process of moving CPython off of OpenSSL releases older than the 1.1.1 series. I suspect that a similar PEP would be required this time around, with similar rationales (around distro + major platform adoption of OpenSSL 3).

Using Distrowatch like in PEP 644, it looks like the biggest remaining LTS users of OpenSSL 1.1.1 are Ubuntu LTS 20.04 and older, Debian Bullseye (11), and OpenSUSE 15.5.

Those are all pretty major users (and some don’t go EOL until 2026, like Bullseye), so I’m not sure if it makes sense to begin thinking about removing 1.1.1 support yet. But I couldn’t find another (direct) discussion of it, so I figured I’d open the conversation up.

2 Likes

Personally, I don’t think there’s much need for a PEP here: it seems fairly uncontroversial to me to drop support for EOL versions of a dependency, particularly when that dependency has such a big impact on the security of Python as a whole that a major security hole in the dependency can cause us to have to expedite a Python release.

The mentioned platforms still on OpenSSL 1.1.1 aren’t going to be shipping Python 3.13; if someone wants to use Python 3.13 on those platforms they’re going to have to build their own (or find a third-party source), and they can just as well provide their own OpenSSL 3.x.

14 Likes

Thanks, that’s encouraging to hear!

In that case, I think there are at least two changesets that make sense here:

  1. Immediate term: turning builds against OpenSSL 1.1.1 into a hard error, probably via #ifdef + #error
  2. Medium term: removing OpenSSL 1.1.1isms from _ssl.c and elsewhere, where present (I believe there aren’t too many of these, since the OpenSSL 3 release was largely API compatible).

If there are no objections to that approach, I can look into filing those.

1 Like

I’d be remiss if I didn’t note that while CPython upstream does not support LibreSSL or BoringSSL, both of their APIs are 1.1.1-ish, and there are folks who maintain patches on CPython to support this.

The net effect of this may be to make life harder for them. They’re not officially supported by us, so that’s life.

But to the extent there are pareto optimal opportunities here (i.e., ways to drop old cruft without making life harder for LibreSSL/BoringSSL users), we should prefer those paths.

4 Likes

Makes sense to me. Given that, doing an #ifdef + #error might cause more heartburn than necessary for those users.

Maybe a lower impact initial step is to drop OpenSSL 1.1.1 from the CPython CI, emphasize that it’s no longer supported (with 3.13) in the docs, but leave _ssl.c mostly untouched for the time being?

1 Like

There’s a big difference between dropping explicit support and intentionally breaking things :slight_smile:

I’m fully on board with dropping 1.1.1 from CI[1], and would support adding a #warning alongside #include "_ssl_data_111.h" though I’m not sure that’s necessary.


  1. on main only; maintenance branches need to keep it ↩︎

3 Likes

I do wish we could get PEP 543 – A Unified TLS API for Python | peps.python.org done and move away from OpenSSL (or even a HTTP fetch API that delegates to the OS so you can bootstrap in whatever you need to get a package that gives you the TLS support you want).

6 Likes

I’m very glad you brought PEP 543 up! A coworker and I have been looking at resurrecting PEP 543 (with a smaller API footprint, in part based on the challenges of exposing a socket-wrapping/callback approach), and we should have more to share on that very soon.

(I’ve hesitated on making a prep-PEP discussion thread for it, since my read of PEP 11 is that I should file the draft PEP first. But, with any luck, we’ll be able to share the draft resurrected PEP within the next week!)

8 Likes

Yeah, please avoid this approach if possible. It’s far more complicated to make cross-platform than we need for the basic TLS functionality that suffers most when it’s missing.

2 Likes

FYI - The kinds of C code changes we make to link CPython against BoringSSL (ported forward to main from what we currently use internally): [Demo] [Incomplete] Allow compilation and linking against BoringSSL by gpshead · Pull Request #116399 · python/cpython · GitHub

Via the issue linked to from the comment on that PR, apparently there are also people linking CPython against an Amazon fork of BoringSSL dubbed AWS-LC.

2 Likes

Well, it took me two months instead of a week :sweat_smile:, but we’ve put a pre-PEP discussion up here: Pre-PEP discussion: revival of PEP 543