[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
Steve Dower
steve.dower at python.org
Thu Jun 1 15:59:15 EDT 2017
On 01Jun2017 1010, Nathaniel Smith wrote:
> I believe that for answering this question about the ssl module, it's
> really only Linux users that matter, since pip/requests/everyone else
> pushing for this only want to use ssl.MemoryBIO on Linux. Their plan on
> Windows/MacOS (IIUC) is to stop using the ssl module entirely in favor
> of new ctypes bindings for their respective native TLS libraries.
>
> (And yes, in principle it might be possible to write new ctypes-based
> bindings for openssl, but (a) this whole project is already teetering on
> the verge of being impossible given the resources available, so adding
> any major extra deliverable is likely to sink the whole thing, and (b)
> compared to the proprietary libraries, openssl is *much* harder and
> riskier to wrap at the ctypes level because it has
> different/incompatible ABIs depending on its micro version and the
> vendor who distributed it. This is why manylinux packages that need
> openssl have to ship their own, but pip can't and shouldn't ship its own
> openssl for many hopefully obvious reasons.)
How much of a stop-gap would it be (for Windows at least) to override
OpenSSL's certificate validation with a call into the OS? This leaves
most of the work with OpenSSL, but lets the OS say yes/no to the
certificates based on its own configuration.
For Windows, this is under 100 lines of C code in (probably) _ssl, and
while I think an SChannel based approach is the better way to go
long-term,[1] offering platform-specific certificate validation as the
default in 2.7 is far more palatable than backporting new public API.
I can't speak to whether there is an equivalent function for Mac
(validate a certificate chain given the cert blob).
Cheers,
Steve
[1]: though I've now spent hours looking at it and still have no idea
how it's supposed to actually work...
More information about the Python-Dev
mailing list