Repository navigation
Use OpenSSL 3.0.x in our binary builds #99079
Description
Activity
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.pyneeds significant modification to "pass" when linked with boringSSL and various pieces of the_sslextension 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.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.
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.
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 ↩
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?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.
48 remaining items
- added 7 commits that reference this issue
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- moved this from Todo to Done in Release and Deferred blockers 🚫
on Jul 31, 2023 What's the plan to update OpenSSL in supported versions 3.8, 3.9, and 3.10?
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. AaslandAny plans to update to Openssl 3.1.x or 3.2.x?
Probably not until OpenSSL declares another Long Term Support version as 3.0.x is per https://www.openssl.org/policies/releasestrat.html
Reacted by gamer191
Metadata
Metadata
Assignees
Projects
- Status
Feature 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