[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

Steve Dower steve.dower at python.org
Thu Jun 8 12:40:27 EDT 2017

I'm just going to straight up admit that I've lost track of the point of 
this thread.

It sounds like we don't *need* to backport any of ssl into the Python 
2.7 standard library, as long as we can bundle a 3rd-party backport for pip?

I assume that, at a high level, the operation needed is to download 
content over https using the system trust stores. Is that what we're 
trying to achieve here?

If it is, can we just provide an enhanced urlretrieve()? Certainly on 
Windows, and presumably on macOS, it's much easier to do the high-level 
GET operation than to reimplement it using primitives.

As far as I can tell (bearing in mind that my brain can't keep track of 
this thread anymore), the only argument against this is if someone wants 
sensible default behaviour with local configuration tweaks: treat one 
specific certificate as valid while also treating the system (and user) 
certificate stores as valid without actually putting your certificate 
into the system (or user) store.

My gut reaction to that is to say "too bad - choices are 100% system 
configuration or 100% custom configuration". I suspect that's not a 
suitable reaction, but I can't explain why. (And bear in mind that the 
current state of the ssl module on Windows will never get 100% system 

Can someone explain to me why pip can't use a simple "system store 
urlretrieve()" function without configuration and "OpenSSL 
urlretrieve()" function with fully custom configuration? Even if only to 
bootstrap something that *can* merge two entirely different 
configuration systems?


More information about the Python-Dev mailing list