> On 24 Feb 2017, at 09:55, Nick Coghlan <ncogh...@gmail.com> wrote:
>
> Heh, I guess you must have already caught everyone with a strong opinion
> about this by way of security-sig :)
So it seems. =D
> On the procedural front, the main open question is whether or not Guido wants
> to review and approve this PEP himself, or if he'd prefer to delegate that
> task.
>
> Assuming the latter case, I think it may make sense for Christian to handle
> the BDFL-Delegate responsibilities as well - I know he's a co-author of the
> PEP, but I also think he's the most qualified to make the final decision on
> the suitability of this design.
Either way, I think I’d like to confirm this works by writing two more modules.
First, I’d like to actually write most of the tls module into something that
can live on PyPI, in no small part because backporting it would be useful for
tools like urllib3. Secondly, I’d like to write a shim for the standard library
ssl module so that I have a clearer picture of whether we want to shim it in
Python code or whether we should take this opportunity to write new bindings to
the C code.
The goal here, essentially, is to have a PoC that the API is at least suitable
for tools like urllib3/requests before we commit to it too much, and the best
way to do that is to prove that the stdlib can meet that API and that at least
one other implementation can do as well. I’ll use SecureTransport for that
proof point, but I’ll make available a branch of urllib3 that has patches
applied to use the new API so that anyone who wants to investigate shimming a
different TLS implementation has got a test suite they can try to run.
Obviously that’s slightly orthogonal to PEP acceptance, but I wanted to keep
people up-to-speed with my thinking.
Cory
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
