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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
