[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7 (original) (raw)

Nathaniel Smith njs at pobox.com
Tue Jun 6 06:08:47 EDT 2017

On Mon, Jun 5, 2017 at 8:49 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

The reason this kind of approach is really attractive to redistributors from a customer risk management perspective is that like gevent's monkeypatching of synchronous networking APIs, it's opt-in at runtime, so the risk of our accidentally inflicting it on a customer that doesn't want it and doesn't need it is almost exactly zero - if none of their own code includes the "import tlsbootstrap; tlsbootstrap.monkeypatchssl()" invocation and none of their dependencies start enabling it as an implicit side effect of some other operation, they'll never even know the enhancement is there. Instead, the compatibility risks get concentrated in the applications relying on the bootstrapping API, since the monkeypatching process is a potentially new source of bugs that don't exist in the more conventional execution models.

OK. To unpack that, I think it would mean:

2.7's ssl.py and _ssl.c remain exactly as they are.

We create a new _tls_bootstrap.py and __tls_bootstrap.c, which start out as ~copies of the current ssl.py and _ssl.c code in master. (Unfortunately the SSLObject code can't just be separated out from _ssl.c into a new file, because the implementations of SSLObject and SSLSocket are heavily intertwined.) Then the copied files are hacked up to work in this monkeypatching context (so that e.g. instead of defining the SSLError hierarchy in C code, it gets imported from the main ssl.py).

So: we end up with two copies of the ssl code in the py27 tree, both diverged from the copy that in the py3 tree, in different ways.

I know that the ssl maintainers won't be happy about this given that keeping the py2 and py3 code similar is an ongoing issue and was one of the stated advantages of backporting SSLObject, but I don't know whether it's a showstopper or not; it'd be good to hear their perspective.

-n

-- Nathaniel J. Smith -- https://vorpus.org

More information about the Python-Dev mailing list