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

Donald Stufft donald at stufft.io
Fri Jun 9 14:18:11 EDT 2017


> On Jun 9, 2017, at 1:07 PM, Steve Dower <steve.dower at python.org> wrote:
> 
> On 09Jun2017 0343, Nick Coghlan wrote:
>> 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)
> 
> My draft reply to Donald sat overnight, so I abandoned it in favour of agreeing with Nick.
> 
> I'm in principle in favour of anything that makes 2.7 less of a burden to maintain (up to and including EOL :) ), so if backporting parts of ssl/_ssl makes that easier then I'm +0.
> 
> However, I do prefer the PyPI backport with some tool bundled in order to obtain it. In fact, given the nature of OpenSSL, I'd be in favour of that approach for all versions of Python (at least on Windows it would likely work well - probably less so on other platforms where we couldn't include a prebuilt fallback easily, though those tend to include compilers...).
> 
> That hypothetical "_ensuressl" module in my mind really doesn't have to do much other than determine which file to download and then download and extract it, which can be done with OS level tools rather than needing our own stack. It may also be the necessary mechanism to make ssl pip-updateable, since we have the locking problem that prevents it being possible normally.
> 


A ensuressl style module that tries to install an OpenSSL module is actually fairly hard to do securely. The fundamental issue being that fetching a file securely from the network before you have the primary tool for fetching things securely from a network gets to be a bit of a chicken and egg problem. There are *possible* ways around that, but they essentially boil down to having to ship something akin to a CA Bundle inside of Python which we just shift the responsibility from needing to have an updated OpenSSL in all versions of Python.

The good news here is that PEP 543 is the thing that will enable using SChannel on Windows, SecureTransport on macOS, and OpenSSL on Linux getting python-dev out of the business of shipping an OpenSSL at all [1]. Backporting ssl.MemoryBio represents the smallest reasonable change to 2.7 we can make [2] that paves the path forward to being able to do that in some number of years, because we can’t do that until PEP 543 is a thing and people are using it.


[1] Ok, the ``ssl`` module is still going to be ssl dependent, and there is a lot of code out there using it so we would need to keep it for awhile to maintain compatibility…. but at some point we can stop bundling it in our installers under the guise of “we have a newer, better API for handling this, and if you still need 2.7 compatibility, here’s the pip installable libraries you need to install to get it”.

[2] Where reasonable means, it’s not sacrificing good things or making things harder to use for the sake of being smaller.

—
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170609/b9c4277c/attachment-0001.html>


More information about the Python-Dev mailing list