> On Jun 2, 2017, at 12:10 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 2 June 2017 at 19:42, Victor Stinner <victor.stin...@gmail.com> wrote: >> Thanks Cory for the long explanation. Let me try to summarize (tell me >> if I'm wrong). >> >> We have 3 options: >> >> * Do nothing: reject the PEP 546 and let each project handles security >> on its own (current status co) >> * Write *new* C code, maybe using certitude as a starting point, to >> offload certifcate validation on Windows and macOS >> * Backport existing code from master to 2.7: MemoryBIO and SSLObject > > There's also a 4th option: > > * Introduce a dependency from requests onto PyOpenSSL when running in > async mode on Python 2.7 in the general case, and figure out some > other pip-specific option for ensurepip bootstrapping (like a > *private* MemoryBIO implementation, or falling back to synchronous > mode in requests) > > During the pre-publication PEP discussions, I kinda dismissed the > PyOpenSSL dependency option out of hand due to the ensurepip > bootstrapping issues it may introduce, but I think we need to discuss > it further in the PEP as it would avoid some of the other challenges > brought up here (Linux distro update latencies, potential > complications for alternate Python 2.7 implementations, etc). >
It’s not just bootstrapping that pip has a problem with for C extensions, it also prevents upgrading PyOpenSSL on Windows because having pip import PyOpenSSL locks the .dll, and we can’t delete it or overwrite it until the pip process exits and no longer imports PyOpenSSL. This isn’t a problem on Linux or macOS or the other *nix clients though. We patch requests as it is today to prevent it from importing simplejson and cryptography for this reason. — Donald Stufft
_______________________________________________ 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
