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

Victor Stinner victor.stinner at gmail.com
Thu Jun 1 13:30:36 EDT 2017

2017-06-01 19:10 GMT+02:00 Nathaniel Smith <njs at pobox.com>:
> (...) 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.

The long term plan include one Windows implementation, one macOS
implementation and one implementation using the stdlib ssl module. But
it seems like right now, Cory is working alone and has limited time to
implement his PEP 543 (new TLS API). The short term plans is to
implement the strict minimum implementation, the one relying on the
existing stdlib ssl module.

Backporting MemoryBIO makes it possible to get the new TLS API "for
free" on Python 2.7. IMHO Python 2.7 support is a requirement to make
the PEP popular enough to make it successful.

The backport is supposed to fix a chicken-and-egg issue :-)

> (And yes, in principle it might be possible to write new ctypes-based
> bindings for openssl, but (...))

A C extension can also be considered, but I trust more code in CPython
stdlib, since it would be well tested by our big farm of buildbots and
have more eyes looking to the code.


It seems like the PEP 546 (backport MemoryBIO) should make it more
explicit that MemoryBIO support will be "optional": it's ok if Jython
or PyPy doesn't implement it. It's ok if old Python 2.7 versions don't
implement it. I expect anyway to use a fallback for those. It's just
that I would prefer to avoid a fallback (likely a C extension)
whenever possible, since it would cause various issues, especially for
C code using OpenSSL: OpenSSL API changed many times :-/


More information about the Python-Dev mailing list