[Python-Dev] PEP 543: A Unified TLS API for Python

[Cory Benfield]

> On 24 Feb 2017, at 09:55, Nick Coghlan <ncoghlan at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170224/6ff90732/attachment-0001.html>