[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.
Cheers,
Steve
More information about the Python-Dev
mailing list