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

Steve Dower steve.dower at python.org
Thu Jun 8 15:57:51 EDT 2017

On 08Jun2017 1237, Donald Stufft wrote:
> The basic yak stak here is:
> * PEP 543 should be the future, it is a much much better way of handling 
> TLS than our current ssl module is.
> * Cory can’t spend his work time on PEP 543 unless he can say it is 
> useful for requests.
> * In order for PEP 543 to be useful for requests, he needs a way to 
> provide a backport for it for Python 2.7.
>     * This backport *CAN* be OpenSSL only, but needs to be able to 
> provide the same API.
> * PEP 543 wants to work with MemoryBIOs instead of sockets, because a 
> MemoryBio is a much much better way of implementing this problem for a 
> variety of reasons, and it would be a mistake to use a socket primitive 
> again.
> * Indepently, requests also wants to be able to provide the ability for 
> people to use it with asyncio, however it can’t drop support for Python 
> 2.7 in the quest for doing that. Twisted provides a way forward that 
> lets requests work on both 2.x and 3.x and integrate with asyncio, but 
> Twisted requires MemoryBio to do so.
> * pyOpenSSL *could* be used to provide the MemoryBio needed on 2.7 for 
> both cases from up above, however, pip cannot depend on a C library that 
> isn’t part of the standard library - in addition this would break 
> alternative runtimes like Jython where pyOpenSSL doesn’t work.

Awesome, this is exactly what I needed to see.

What if Python 2.7 just exposed the OpenSSL primitives necessary so that 
ctypes could use them? Is that a viable approach here? Presumably then a 
MemoryBIO backport could be pure-Python.

It doesn't help the other *ythons, but unless they have MemoryBIO 
implementations ready to backport then I can't think of anything that 
will help them short of a completely new API.


More information about the Python-Dev mailing list