[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7 (original) (raw)

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

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?

Cheers, Steve

More information about the Python-Dev mailing list