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

Nick Coghlan ncoghlan at gmail.com
Fri Jun 9 06:43:16 EDT 2017


On 9 June 2017 at 05:51, Donald Stufft <donald at stufft.io> wrote:
> And the downside here is pretty small honestly?

Unfortunately, one of the downsides is "Doesn't provide any clearly
compelling benefits to users of LTS distributions, so even those of us
in a position to advocate for such backports probably won't win the
related arguments".

So the question is whether or not we're OK with saying that users
affected by that will need to switch to a different set of Python
binaries to get the latest pip & requests (e.g. upgrading their base
distro, or else adopting Red Hat SCLs or one of the cross-platform,
and hence cross-distro, distributions).

> It’s not changing behavior of anything that currently exists since it’s
> adding a new thing inside the ssl module and Alex has already written the
> patch so there’s little extra work to do and it actually makes maintenance
> easier since patches can more readily be applied straight from `master`.
>
> The primary argument I can see against it, is one of purity, that 2.7
> shouldn’t get new features but as we know, practicality beats purity ;) (and
> we’ve already accepted that TLS is a special case, special enough to break
> the rules, so the main question is whether this specific thing is
> worthwhile— which given it’s benefits to the Python ecosystem and to
> maintaining Python, I think it is).

It isn't a purity argument so much as a "Will the change reach a
sufficiently large proportion of 2.7 users to actually solve the
compatibility problem it is aiming to solve?" argument (There's a
*bit* of a purity argument behind that, in that the PEP 466 backport
*did* break customer applications due to the incompatibilities with
some of the async frameworks that were using underscore prefixed APIs
that changed behaviour, so our credibility for "trust us, it won't
break anything" is low in this context, but it's not the primary
objection)

I'm 100% confident that we'd reach a large enough audience with a
compatibility shim that gets installed on disk as something other than
"ssl" (e.g. "backport.ssl" or "_ssl_bootstrap"), and that has the
virtue of enabling a multi-tiered distribution approach:

- backport.ssl on PyPI as an independently installed module
- _ssl_bootstrap as a runtime or redistributor provided module

This approach also allows the API to be updated as necessary to meet
the needs of PEP 543, without needing to go through the full PEP
process again. The downside is adding a 3rd stack to maintain (Py3,
Py2-compatible Py3 backport, Py2) without making maintenance on the
Py2 stack any easier.

I'm markedly less confident of reaching a sufficiently large audience
with a "So stop using the system Python, then" approach (Don't get me
wrong, I'd love for people to stop using the system Python for things
that aren't part of the operating system, but people also *really
like* the convenience of doing that).

OTOH, if the aim is to make the change now, so it gets into Ubuntu
18.04, with a view to projects only starting to fully rely on it in
mid-to-late 2018 or so? That timeline might actually work, and this
approach has the benefit of actually making the Py2 SSL stack easier
to maintain between now and 2020.

So honestly, I'd be +1 for either approach:

- stdlib backport to make dual-stack maintenance easier for the
current volunteers, and we'll see how things work out on the
ease-of-adoption front
- PyPI backport to make 2.7 adoption easier, and we'll continue
pestering redistributors to actually fund maintenance of Python 2.7's
SSL stack properly (and encourage customers of those redistributors to
do the same)

Cheers,
Nick.

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


More information about the Python-Dev mailing list