# Pathway to requiring OpenSSL 3 or newer in CPython? **URL:** \ **Category:** Core Development\ **Tags:** security\ **Created:** [February 16, 2024, 2:17am UTC](https://discuss.python.org/t/pathway-to-requiring-openssl-3-or-newer-in-cpython/46055 "2024-02-16T02:17:18Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![woodruffw](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/woodruffw/32/37228_2.png) [@woodruffw](https://discuss.python.org/u/woodruffw)\ **Post date:** [February 16, 2024, 2:17am UTC](https://discuss.python.org/t/pathway-to-requiring-openssl-3-or-newer-in-cpython/46055/1 "2024-02-16T02:17:18Z")
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 🙂 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](https://peps.python.org/pep-0644/) 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. ---
**Author:** ![zware](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/zware/32/58_2.png) [@zware](https://discuss.python.org/u/zware)\ **Post date:** [February 16, 2024, 2:48am UTC](https://discuss.python.org/t/pathway-to-requiring-openssl-3-or-newer-in-cpython/46055/2 "2024-02-16T02:48:29Z")
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. ---
**Author:** ![woodruffw](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/woodruffw/32/37228_2.png) [@woodruffw](https://discuss.python.org/u/woodruffw)\ **Post date:** [February 16, 2024, 2:37pm UTC](https://discuss.python.org/t/pathway-to-requiring-openssl-3-or-newer-in-cpython/46055/3 "2024-02-16T14:37:05Z")
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. ---
**Author:** ![alex\_Gaynor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/alex_gaynor/32/17_2.png) [@alex\_Gaynor](https://discuss.python.org/u/alex_Gaynor)\ **Post date:** [February 16, 2024, 2:51pm UTC](https://discuss.python.org/t/pathway-to-requiring-openssl-3-or-newer-in-cpython/46055/4 "2024-02-16T14:51:28Z")
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. ---
**Author:** ![woodruffw](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/woodruffw/32/37228_2.png) [@woodruffw](https://discuss.python.org/u/woodruffw)\ **Post date:** [February 16, 2024, 3:00pm UTC](https://discuss.python.org/t/pathway-to-requiring-openssl-3-or-newer-in-cpython/46055/5 "2024-02-16T15:00:59Z")
> [@alex\_Gaynor](#): > > 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. 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? ---
**Author:** ![zware](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/zware/32/58_2.png) [@zware](https://discuss.python.org/u/zware)\ **Post date:** [February 16, 2024, 4:48pm UTC](https://discuss.python.org/t/pathway-to-requiring-openssl-3-or-newer-in-cpython/46055/6 "2024-02-16T16:48:57Z")
There’s a big difference between dropping explicit support and intentionally breaking things 🙂 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 ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 16, 2024, 9:15pm UTC](https://discuss.python.org/t/pathway-to-requiring-openssl-3-or-newer-in-cpython/46055/7 "2024-02-16T21:15:02Z")
I do wish we could get [PEP 543 – A Unified TLS API for Python | peps.python.org](https://peps.python.org/pep-0543/) 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). ---
**Author:** ![woodruffw](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/woodruffw/32/37228_2.png) [@woodruffw](https://discuss.python.org/u/woodruffw)\ **Post date:** [February 16, 2024, 9:37pm UTC](https://discuss.python.org/t/pathway-to-requiring-openssl-3-or-newer-in-cpython/46055/8 "2024-02-16T21:37:42Z")
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!) ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [February 19, 2024, 7:30pm UTC](https://discuss.python.org/t/pathway-to-requiring-openssl-3-or-newer-in-cpython/46055/9 "2024-02-19T19:30:50Z")
> [@woodruffw](#): > > with a smaller API footprint, in part based on the challenges of exposing a socket-wrapping/callback approach 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. ---
**Author:** ![gpshead](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/gpshead/32/54_2.png) [@gpshead](https://discuss.python.org/u/gpshead)\ **Post date:** [March 6, 2024, 1:38am UTC](https://discuss.python.org/t/pathway-to-requiring-openssl-3-or-newer-in-cpython/46055/10 "2024-03-06T01:38:04Z")
FYI - The kinds of C code changes we make to link CPython against [BoringSSL](https://boringssl.googlesource.com/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](https://github.com/python/cpython/pull/116399) 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](https://github.com/aws/aws-lc). ---
**Author:** ![woodruffw](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/woodruffw/32/37228_2.png) [@woodruffw](https://discuss.python.org/u/woodruffw)\ **Post date:** [April 17, 2024, 8:46pm UTC](https://discuss.python.org/t/pathway-to-requiring-openssl-3-or-newer-in-cpython/46055/11 "2024-04-17T20:46:23Z")
> [@woodruffw](#): > > (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!) Well, it took me two months instead of a week 😅, but we’ve put a pre-PEP discussion up here: [Pre-PEP discussion: revival of PEP 543 - A Unified TLS API for Python](https://discuss.python.org/t/pre-pep-discussion-revival-of-pep-543/51263)