[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7 (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Jun 5 09:59:18 EDT 2017

On 5 June 2017 at 21:44, Donald Stufft <donald at stufft.io> wrote:

Is pip allowed to use the hypothetical ensurepipssl outside of ensurepip?

Yes, so something like _tls_bootstrap would probably be a better name for the helper module (assuming we go down the "private API to bootstrap 3rd party SSL modules" path).

The leading underscore would be akin to the one on _thread - it isn't that the API would be undocumented or inaccessible, it's that it wouldn't have any backwards compatibility guarantees for general use, so you shouldn't use it without a really good reason.

Thinking about this reminded me about the other reason pip avoids dependencies— avoiding making assertions about what versions of software can actually be installed. IOW if pip depends on pyOpenSSL >= X.Y, then you essentially can’t install any other version of pyOpenSSL and you’d be forced to upgrade.

Indeed, and I think that's sufficient justification for at least adding the private TLS bootstrapping API.

This isn’t end of the world and pyOpenSSL is generally stable enough we could probably get away with a unversioned dependency on a non Windows platform. On Windows we’d have to uh, I guess use a SChannel c-types backend? Not having our TLS library in the stdlib makes it a bit more difficult, but from pip’s own POV if there’s a MemoryBio that we’re allowed to use and then requests uses pyOpenSSL normally (we’d apply a small patch to pip’s copy of requests to make it use it, but that’s easy to do with our setup) I think that would be workable.

I think that’s a less optimal solution than just accepting PEP 546 which I think is beneficial to the Python ecosystem as a whole, making it easier to port more code onto 3.x (and allowing unlocking 3.x’s capabilities) and will make it easier to maintain the ssl library on 2.7, given it will have less of a divergence from 3.x again.

Right, I'm just trying to make sure we clearly separate the two arguments: pip bootstrapping (which can potentially be addressed through a private alternate SSL/TLS API) and ecosystem advancement (making it easier for SSL/TLS capable applications to retain Python 2.7.x compatibility at least until 2020, while still supporting the improvements in asynchronous IO capabilities in the 3.x series).

Separating the two main options like that gives us two future scenarios:

  1. Private TLS bootstrapping API
  1. Public standard library ssl module API update

So honestly, I don't think the current "ecosystem advancement" argument in PEP 546 actually works, as the enhancement is significantly easier to roll out to older 2.7.x releases if the adoption model is "Supporting SSL/TLS with sans-io style protocol implementations on Python versions prior to Python 3.5 requires the use of PyOpenSSL or a suitable PEP 543 compatible library (unless you're a package management tool, in which case you should check for a separate platform provided Python version independent _tls_bootstrap module before falling back to PyOpenSSL)".

As long as we actually document the _tls_bootstrap API (even if that's just a cross-reference to the Python 3.6 ssl module documentation), then folks wanting to share asynchronous IO code between Python 2 & 3 will have the following options:

Cheers, Nick.

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

More information about the Python-Dev mailing list