> On Jan 11, 2017, at 10:40 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 12 January 2017 at 13:00, Donald Stufft <don...@stufft.io> wrote: >> This doesn’t work well because it’s not something that pip is going to be >> able to upgrade on Windows, because the .so will be locked when pip imports >> it on Windows and we won’t be able to uninstall it to do an upgrade. We had >> to disable the automatic use of pyOpenSSL for this reason too. The only C >> stuff that pip can reliably use is the standard library. > > Ugh, I'd completely forgotten about that limitation of Windows filesystems. > > And the main alternatives I can think of involve copying files around > as pip starts up, which would be unacceptably slow for a command line > app :( >
I don’t think it’s a particularly big deal to tie the tls module to the Python lifecycle though, we’ve got a precident for PEPs that backport important security critical stuff and most things are presumably going to be things that we don’t really even need a backport or a PEP for (I’m thinking things like ciphers and such). Particularly if this new thing is documented up front clearly what things you can depend on for compatibility (api and such) and what things can change in minor releases (keeping up with the security joneses stuff). I think the big thing that really killed the ssl module for so long in Python was the 2.x vs 3.x split with 2.7 living for a _very_ long time, and then no culture of back porting security important changes to it. — Donald Stufft
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
