[Python-ideas] Unified TLS API for Python

[Christian Heimes]

On 2017-02-04 19:18, Cory Benfield wrote:
> 
>> On 3 Feb 2017, at 18:30, Steve Dower <steve.dower at python.org> wrote:
>>
>> On 02Feb2017 0601, Cory Benfield wrote:
>>>
>>> 4. Eventually, integrating the two backends above into the standard
>>> library so that it becomes possible to reduce the reliance on OpenSSL.
>>> This would allow future Python implementations to ship with all of their
>>> network protocol libraries supporting platform-native TLS
>>> implementations on Windows and macOS. This will almost certainly require
>>> new PEPs. I’ll probably volunteer to maintain a SecureTransport library,
>>> and I have got verbal suggestions from some other people who’d be
>>> willing to step up and help with that. Again, we’d need help with
>>> SChannel (looking at you, Steve).
>>
>> I'm always somewhat interested in learning a new API that I've literally never looked at before, so yeah, count me in :) (my other work was using the trust APIs directly, rather than the secure socket APIs).
>>
>> PyCon US sprints? It's not looking like I'll be able to set aside too much time before then, but I've already fenced off that time.
> 
> That might be a really good idea.
> 
> With feedback from Nathaniel and Glyph I’m going back to the drawing board a bit with this PEP to see if we can reduce the amount of work needed from backends, so this may shrink down to something that can feasibly be done in a sprint.
> 
> For those who are interested, the refactoring proposed by Nathaniel and Glyph is to drop the abstract TLSWrappedSocket class, and instead replace it with a *concrete* TLSWrappedSocket class that is given a socket and an implementation of TLSWrappedBuffers. This would essentially mean that implementations only need to write a TLSWrappedBuffers implementation and would get a TLSWrappedSocket essentially for free (with the freedom to provide a complete reimplementation of TLSWrappedSocket if they need to).
> 
> I’m going to investigate the feasibility of that by writing a stub TLSWrappedBuffers for SecureTransport and then writing the TLSWrappedSocket implementation to validate what it looks like. Assuming the end result looks generally suitable, I’ll come back with a new draft. But the TL;DR is that if we do that all we need to implement on the Windows side is one-or-two classes, and we’d be ready to go. That’d be really nice.

At first I was a bit worried that you were planning to chance the
semantic of socket wrapping. The PEP doesn't get into detail how
wrap_socket() works internally. How about you add a paragraph that the
function wraps an OS-level file descriptors (POSIX) or socket handles
(Windows).

For some TLS libraries it's an optimization to reduce memory copies and
overhead of extra GIL lock/unlock calls. Other TLS libraries (NSS, Linux
kernel TLS with AF_KTLS) can only operator on file descriptors. In fact
NSS can only operator on NSPR PRFileDesc, but NSPR has an API to wrap an
OS-level fd in a PRFileDesc.

By the way, how can a TLS implementation announce that it does not
provide buffer wrapping?

Christian