[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
Steve Dower
steve.dower at python.org
Fri Jun 9 15:41:33 EDT 2017
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...
Cheers,
Steve
More information about the Python-Dev
mailing list