[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

[Nick Coghlan]

On 2 June 2017 at 19:42, Victor Stinner <victor.stinner at 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).

For example:

* if requests retains a synchronous mode fallback implementation, then
ensurepip could use that in the absence of PyOpenSSL
* even if requests drops synchronous mode entirely, we could leave the
public ssl module API alone, and add an _ensurepip bootstrap module
specifically for use in the absence of a full PyOpenSSL module

If we adopted the latter approach, then for almost all intents and
purposes, ssl.MemoryBIO and ssl.SSLObject would remain a Python 3.5+
only API, and anyone wanting access to it on 2.7 would still need to
depend on PyOpenSSL.

The benefit of making any backport a private API is that it would mean
we weren't committing to support that API for general use: it would be
supported *solely* for the use case discussed in the PEP (i.e. helping
to advance the development of PEP 543 without breaking pip
bootstrapping in the process).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia