On 24 May 2017 at 14:27, Nathaniel Smith <n...@pobox.com> wrote: > On Tue, May 23, 2017 at 8:34 PM, David Wilson <dw+python-...@hmmz.org> wrote: >> On Tue, May 23, 2017 at 06:13:17PM -0700, Cory Benfield wrote: >> >>> There are discussions around Requests unvendoring its dependencies >>> thanks to the improved nature of pip. This might be a year of pretty >>> big changes for Requests. >> >> In which case, what is to prevent Requests from just depending on >> pyOpenSSL as usual? > > I thought that requests couldn't have any hard dependencies on C > extensions, because pip vendors requests, and pip needs to be > pure-python for bootstrapping purposes? Cory would know better than me > though, so perhaps I'm wrong...
You're not wrong - even if requests itself stops bundling its dependencies in its releases, pip will still need to bundle requests and all its dependencies for bootstrapping purposes, which rules out a hard dependency on PyOpenSSL (since even with manylinux1 available, the wheel format doesn't offer 100% coverage of all environments where pip will need to be bootstrapped). >> I'm still writing 2.7 code every day and would love to see it live a >> little longer, but accepting every feature request seems the wrong way >> to go - and MemoryBIO is a hard sell as a security enhancement, it's new >> functionality. > > IIUC, the security enhancement is indirect but real: on Windows/MacOS, > Python's dependence on openssl is a security liability, and to get > away from this we need Cory's new library that abstracts over > different TLS implementations. But for applications to take advantage > of this, they need to switch to using the new library. And before they > can switch to using the new library, it needs to work everywhere. And > for the new library to work on python 2 on unix, it needs MemoryBIO's > in the stdlib – ideally using an interface that's as-close-as-possible > to what they look like on python 3, so he doesn't have to implement > totally different backends for py2 and py3, because Cory is already a > hero for trying to make this happen and we don't want to waste any > more of his time than necessary. So the end result is that if you have > Python 2 code doing SSL/TLS on Windows/MacOS, and you want proper > trust handling and prompt security updates, then MemoryBIO support is > actually on the critical path for making that happen. I believe you just wrote the "Rationale" section of the backport PEP :) The other key aspect potentially worth mentioning is that upstream approving the backport for a future 2.x maintenance release means that downstream redistributors are also free to add it to their(/our) long term support releases without introducing vendor specific divergences (i.e. the feature being missing becomes just a typical "your Python is too old, you'll have to install PyOpenSSL" problem, rather than a "your Python is from the wrong redistributor" problem - while the latter can still happen sometimes for various reasons, it's something we collectively try to avoid). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
