On 2017-02-04 19:18, Cory Benfield wrote: > >> On 3 Feb 2017, at 18:30, Steve Dower <steve.do...@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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
