> On 2 Feb 2017, at 11:03, Robert Collins <robe...@robertcollins.net> wrote:
>
> Nice. What's needed to move this forward?
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.
Longer term, the following chunks of work will be needed:
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.
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.
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.
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).
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).
Cory
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
