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

[Nathaniel Smith]

On Jun 1, 2017 9:20 AM, "Chris Angelico" <rosuav at gmail.com> wrote:

On Fri, Jun 2, 2017 at 1:01 AM, Cory Benfield <cory at lukasa.co.uk> wrote:
> The answer to that is honestly not clear to me. I chatted with the pip
developers, and they have 90%+ of their users currently on Python 2, but
more than half of those are on 2.7.9 or later. This shows some interest in
upgrading to newer Python 2s. The question, I think, is: do we end up in a
position where a good number of developers are on 2.7.14 or later and only
a very small fraction on 2.7.13 or earlier before the absolute number of
Python 2 devs drops low enough to just drop Python 2?
>
> I don’t have an answer to that question. I have a gut instinct that says
yes, probably, but a lack of certainty. My suspicion is that most of the
core dev community believe the answer to that is “no”.
>

Let's see.

Python 2 users include people on Windows who install it themselves,
and then have no mechanism for automatic updates. They'll probably
stay on whatever 2.7.x they first got, until something forces them to
update. But it also includes people on stable Linux distros, where
they have automatic updates provided by Red Hat or Debian or whomever,
so a change like this WILL propagate - particularly (a) as the window
is three entire years, and (b) if the change is considered important
by the distro managers, which is a smaller group of people to convince
than the users themselves.


I believe that for answering this question about the ssl module, it's
really only Linux users that matter, since pip/requests/everyone else
pushing for this only want to use ssl.MemoryBIO on Linux. Their plan on
Windows/MacOS (IIUC) is to stop using the ssl module entirely in favor of
new ctypes bindings for their respective native TLS libraries.

(And yes, in principle it might be possible to write new ctypes-based
bindings for openssl, but (a) this whole project is already teetering on
the verge of being impossible given the resources available, so adding any
major extra deliverable is likely to sink the whole thing, and (b) compared
to the proprietary libraries, openssl is *much* harder and riskier to wrap
at the ctypes level because it has different/incompatible ABIs depending on
its micro version and the vendor who distributed it. This is why manylinux
packages that need openssl have to ship their own, but pip can't and
shouldn't ship its own openssl for many hopefully obvious reasons.)

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170601/a8d90d6f/attachment.html>