[Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Nick Coghlan]

On 24 May 2017 at 14:27, Nathaniel Smith <njs at pobox.com> wrote:
> On Tue, May 23, 2017 at 8:34 PM, David Wilson <dw+python-dev at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia