
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 2 Feb 2017, at 11:03, Robert Collins <<a href="mailto:robertc@robertcollins.net" class="">robertc@robertcollins.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="">Nice. What's needed to move this forward?</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div>

</div></blockquote><br class=""></div><div>In the short term, for the PEP, nothing more than review and sanity checking. Antione has kindly provided some detailed review on GitHub (thanks Antoine!), and the more of that we get the better. Once review has quieted down for a few days, I’ll take that as something approximating consensus from this list, and I’ll kick it over to python-dev and start the formal PEP process.</div><div><br class=""></div><div>Longer term, the following chunks of work will be needed:</div><div><br class=""></div><div>1. Providing a shim for the current ssl module. The ssl module has a number of objects that don’t quite cleave to this API, so we’d probably want to either add new objects that do that (likely by wrapping the current ones), or we’d want a whole-new module that cleaves to this API. I’ll discuss more in my response to Paul what I think we’d do with the ssl module longer-term.</div><div>2. Code needs to be written for the identified network libraries to have them use the new API. There’s no point doing this until (1) is done, as they’ll otherwise have no ability to use any TLS API at all, but transitioning over to the new API starts providing some real community value as third-party implementations can start being used with stdlib network modules.</div><div>3. Backends for SChannel and SecureTransport would need to be written. The most likely response I expect from Guido and others in python-dev is that they’d like to see example implementations for SChannel and SecureTransport that fit this API. I am likely to stub out a SecureTransport implementation sometime soon, as I have some experience with that API, and it’d make a good test-bed for the PEP. I’m a bad fit for doing SChannel though: I don’t know Windows well enough, and my ramp-up time would be high. I’ll scout out to see if there’s someone who’s willing to stub this out, though.</div><div>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).</div><div><br class=""></div><div>These are all valuable things to do, and I’d accept help with any and all of them. Certainly we need to do (1) and (2) to start getting real value out of this PEP, with (3) being something that could be done third-party initially (and so don’t have to land in Python 3.7).</div><div><br class=""></div><div>Cory</div></body></html>