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

Donald Stufft donald at stufft.io
Fri Jun 9 15:54:10 EDT 2017

> On Jun 9, 2017, at 3:41 PM, Steve Dower <steve.dower at python.org> wrote:
> On 09Jun2017 1118, Donald Stufft wrote:
>> 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.
> One of the reasons I'm wanting to push this way is that there are other APIs on Windows to do the core client use cases we seem to care about.
> For example, https://msdn.microsoft.com/en-us/library/windows/desktop/aa384106(v=vs.85).aspx could easily let us implement the requests API with a direct call to the operating system, without having to get into the SChannel world of hurt. I assume macOS has similarly high-level APIs.
> These are totally fine for implementing a requests-like API that relies on system configuration for HTTPS connections. They are not sufficient for building a server, but they should be sufficient for downloading the packages you need to build a server.
> This is starting to feel to me like we're stuck on "building the thing right" and have skipped over "building the right thing". But maybe it's just me…

I’m personally not super interested in having platform specific HTTP handling. I honestly want as little platform specific code as I can get away with, and the primary reason why I’m okay with drawing the line at the TLS stack (instead of the HTTP stack) is because being able to get operating system updates for the TLS stack is of immense benefit in addition to the fact that it’s really the *only* reasonable way to get access to the platform specific trust store.

Relying on the OS to handle HTTP means that we cannot depend on anything that isn’t the lowest common denominator across all of the variety of platforms we support, which (as I see Cory has mentioned) isn’t really a thing outside of macOS/Windows. For those platforms we’d just be adding yet another C dependency to Python (or pip, or requests, or whatever). There’s a lot of HTTP handling code in pip that would need to be rewritten to support this, and I don’t think it would be of a particular benefit much less be doable in any reasonable timeframe.

This isn’t really being particularly innovative in this area, it’s essentially what the browsers are doing. It also matches what curl is doing.

All that being said, if someone *does* want pip to use WinHTTP, requests provides a mechanism where you can plug in your own network handling code, so someone could write a requests-winhttp adapter that did that, and we could possibly even expose the ability to ask pip to use that. However that’s entirely in the domain of pip/requests feature requests and not really related to python-dev/this PEP itself.

Donald Stufft

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

More information about the Python-Dev mailing list