[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).


[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