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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
