[Demo] [Incomplete] Allow compilation and linking against BoringSSL #116399
Conversation
Does not include configure.ac or Makefile.ac changes. The _ssl_data changes are hand created rather than properly updating the code generator. A future upstream API is anticipated to deal with those better anyways.
BoringSSL, for now, does not provide these APIs because of design flaws in the API. When we've disentangled this mess, and implemented the functions in BoringSSL, this patch can be removed.
It adds an ill-advised feature that BoringSSL can't support.
This concurrency fix needs reworking for use with BoringSSL.
Don't test for hash functions that are entirely optional for a TLS implementation. This configure check should be reworked anyways, even md5 and sha1 could possibly not be present (FIPS?).
|
For some context, some of the changes can probably be reduced. In particular, I plan to implement the "ex" versions of SSL_read and SSL_write. We'd skipped them originally because OpenSSL messed them up. (They forgot EOF was different from error.) But between a fix I landed in CPython a bit ago and some ideas we had on our end, I think we can implement them without picking up the problems from OpenSSL's version. Likewise I think the way to resolve errors is to add new API to return the symbol name of things. OpenSSL hasn't been responsive to this feature request but I plan to just go ahead and add them on our end. |
some manual fixups, more testing and post-fixing will be required.
Python needs to map OpenSSL error codes like ERR_R_INTERNAL_ERROR into strings like "INTERNAL_ERROR". OpenSSL lacks an API for this, so CPython instead maintains its own table. This table is necessarily sensitive to the OpenSSL version and causes issues for BoringSSL. Rather than maintain our own copy of this table, BoringSSL has APIs to do the thing CPython actually wants. This patch switches CPython to use them. To keep the patch small, it doesn't ifdef the err_codes_to_names, etc., fields, but they are no longer necessary. See openssl/openssl#19848 and https://discuss.python.org/t/error-tables-in-the-ssl-module/25431 for context. BoringSSL API addition: https://boringssl.googlesource.com/boringssl/+/dbad745811195c00b729efd0ee0a09b7d9fce1d2
BoringSSL was originally missing BIO_FP_TEXT preventing the keylog callback API from working. That was added to BoringSSL.
| @@ -4542,50 +4582,6 @@ set_sni_callback(PySSLContext *self, PyObject *arg, void *c) | |||
| return 0; | |||
| } | |||
|
|
|||
| #if OPENSSL_VERSION_NUMBER < 0x30300000L | |||
There was a problem hiding this comment.
Oh BoringSSL supports get1_objects. My thinking was we'd just update this ifdef to skip the polyfill in BoringSSL and then leave the rest as-is. get1_objects avoids a race condition in the old CPython code. (get0_objects was added to OpenSSL for CPython, but it turned out to have been the wrong API the whole time. get1_objects was to undo that mistake)
|
From the BoringSSL README:
It seems odd to then add support for building Python against BoringSSL, unless there will be a guarantee of API/ABI stability. If that is indeed the case, which version will be considered stable? That would be the one that CPython should target. If this lands for 3.14, such a theoretical BoringSSL API/ABI would need to be supported until October 2030; what would the maintenance cycle look like? If there is a security issue requiring an API change that is relevant to already-released CPython versions, what would the disclosure process look like? |
NOTE: This is focused solely on the C code changes required. It is not usable as is. Missing items if you were to attempt to use this yourself: build system changes necessary for this to work have not been completed -- we don't use CPython's build system when building the runtime at Google.
The purpose of opening this as a Draft PR is to show what kinds of changes are currently needed. I'm not aiming to see this merged as is - though we may choose pull bits and pieces out into their own small PRs that could make sense on their own to minimize the changes necessary for those using other TLS libraries where easily maintainable.
It may be of potential interest to some ongoing discussions (I expect to link to it) and issue #116333 authors and its draft PR #116334.
Playing around with hackish quick attempts (mostly not yet included in the PR branch) at using CPython's existing build system:
_sslmodule being available fails otherwise.Modules/_hashopenssl.c_ssland_hashlibmodules as that is its intent (this requiresModules/Setup*changes)Proper configure.ac, Setup, & Makefile.pre.in plumbing would be needed to alleivate all of this.
📚 Documentation preview 📚: https://cpython-previews--116399.org.readthedocs.build/