@gpshead Out of curiosity, Did we have any discussion about using boringSSL by vendoring them to the CPython repo?

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.

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 everywhere¹), 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.