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

[Donald Stufft]

> On Jun 8, 2017, at 3:57 PM, Steve Dower <steve.dower at python.org> wrote:
> 
> 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.
> 


I would have to let Cory answer the question about feasibility here since he’s much more familiar with OpenSSL’s API (and even binding something like this with ctypes) than I am. The first thing that really stands out to me though is it just feels a bit like shuffling deckchairs?

At least I don’t see what adding the new feature of “thing you can use ctypes with to get a MemoryBio” does that adding the ssl.MemoryBio feature doesn’t other than downsides:

* It creates yet another divergence between 3.x and 2.x that makes it harder to maintain ssl and _ssl.
* It’s harder to use for requests/Twisted/etc.
* It’s not already written (Ok this is minor, but still!).

What do you see the benefits of that approach being over just backporting ssl.MemoryBio?

—
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170608/ed01d7e9/attachment.html>