GeezerVison is showing github.com — Use OpenSSL 3.0.x in our binary builds · Issue #99079 · python/cpython
Use OpenSSL 3.0.x in our binary builds #99079DescriptionFeature or enhancement
We currently use OpenSSL 1.1.1 series in our Windows and macOS binary builds.
Per https://www.openssl.org/source/, that is only supported through September of 2023.
Thus we need to switch to a supported version of OpenSSL before 3.12 is released. (And likely consider moving 3.11 to use it if deemed feasible)
There are a pile of bugs related to OpenSSL 3 that may or may not be blockers:
We have a longer term desire to not be so beholden to OpenSSL at all. But this issue is being filed as a practical response to untangling that not being likely feasible before 3.12beta1.
Linked PRs
Activitycorona10 commented on Nov 6, 2022 @gpshead Out of curiosity, Did we have any discussion about using boringSSL by vendoring them to the CPython repo? gpshead commented on Nov 11, 2022
Did we have any discussion about using boringSSL by vendoring them to the CPython repo?
I'm not sure how well that would work out. boringSSL isn't really intended to be used by other projects, it doesn't guarantee a stable API. Even for security updates. And it lacks some interfaces and features.
test_ssl.py needs significant modification to "pass" when linked with boringSSL and various pieces of the _ssl extension code need modifications as well as workarounds to disable unsupported features in some places. We carry patches on our Python runtime internally at Google that does some this, but they wouldn't be acceptable as is upstream as they disable features that need to work for global users and skip some tests rather than making them work. If we want to consider official boringSSL support in the CPython repo as well that should get tracked in another issue.
corona10 commented on Nov 11, 2022
it doesn't guarantee a stable AP
Oh, I thought that we can manage the boringSSL as the vendored library likewise libexpat or mimalloc.
We carry patches on our Python runtime internally at Google that does some this, but they wouldn't be acceptable as is upstream as they disable features that need to work for global users and skip some tests rather than making them work
Oh got it..
If we want to consider official boringSSL support in the CPython repo as well that should get tracked in another issue.
Yeah and we also need to write PEP also if we try to do, but we may need to know the possibility of the porting boringSSL into our repository first. gpshead commented on Nov 11, 2022
it doesn't guarantee a stable AP
Oh, I thought that we can manage the boringSSL as the vendored library likewise libexpat or mimalloc.
We could and would if we did this. It's mostly noteworthy as a risk as it could involve some refactoring larger than we like to do within security fix releases several years down the line in order to pull in other updates. h-vetinari commented on Nov 29, 2022
Did we have any discussion about using boringSSL by vendoring them to the CPython repo?
Now on DPO!
Moving away from OpenSSL completely has some large maintenance benefits (but IMO even larger downsides too).
Moving to boringSSL sounds like a very bad proposition to my mind. OpenSSL is a heavy dependency, but it goes very far out of its way in terms of stability (which nowadays includes being buildable everywhere1), e.g. it promises:
- No API or ABI breaking changes are allowed in a minor or patch release.
- No existing public interface can be modified except where changes are unlikely to break source compatibility [...]
- No existing public interface can be removed until its replacement has been in place in an LTS stable release. The original interface must also have been documented as deprecated for at least 5 years.
I don't see sufficiently huge issues with OpenSSL (or sufficiently huge improvements with boringSSL) that a switch would look even remotely reasonable from my POV.
Footnotes
-
not least still being on C89 to support some ultra-exotic platforms without modern compilers ↩
mzhao-dev commented on Jan 30, 2023 I built python 3.11.1 with OPENSSL 3.0.7 on windows 10 platform, when I run test_ssl.py, it shows no OPENSSL_Applink, error and crashed.
I confirmed that applink.c file was added and complied, so I have no idea about that issue. I think maybe need some other code change about that?
#101401 gpshead commented on Apr 27, 2023 Marking this as a release blocker again because we really should do this before beta1 so that people test against a relevant representation of what the next release will contain. ned-deily commented on Jul 31, 2023 I think we are done here: as of 3.12.0rc1 and 3.11.5, Windows builds and downloads from python.org for Windows and macOS should be using OpenSSL 3.0 (currently 3.0.9). Reacted by Erlend E. Aasland and Dmitriy Pertsev lennin-cp commented on Aug 25, 2023 What's the plan to update OpenSSL in supported versions 3.8, 3.9, and 3.10? zware commented on Aug 26, 2023
What's the plan to update OpenSSL in supported versions 3.8, 3.9, and 3.10?
None: binaries are no longer produced for these versions, and the code is already compatible (enough). Reacted by Erlend E. Aasland gamer191 commented on Apr 8, 2024 Any plans to update to Openssl 3.1.x or 3.2.x? gpshead commented on Apr 8, 2024
MetadataMetadataStatusShow more project fields StatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|