<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 14 February 2017 at 00:26, Cory Benfield <span dir="ltr"><<a href="mailto:cory@lukasa.co.uk" target="_blank">cory@lukasa.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
Python has never exposed the ability to use TLS backends other than OpenSSL in the standard library. As Christian and I discussed back at the Developer Summit at PyCon US 2016, the ssl module would more properly be called the openssl module, due to exposing many OpenSSL-specific concepts and behaviours in its API. This has meant that the Python ecosystem is overwhelmingly also an OpenSSL ecosystem, which is problematic on Windows and macOS (and Unices that for whatever reason aren’t interested in shipping an OpenSSL), as it has meant that Python needs to bring its own OpenSSL, and that it is troublesome to interact with the system trust database.<br>
<br>
The first step to resolving this would be to provide a new module that exposes TLS concepts in a much more generic manner. There are two possible approaches to this. The first is to have this module be a generic concrete implementation that can be compiled against multiple TLS backends (like curl). This would require that all the relevant bindings be built into the standard library from the get-go, which provides a substantial maintenance burden on a team of people that are already understaffed maintaining the ssl module alone. The second approach is to define a generic high-level TLS interface that provides a minimal usable interface that can be implemented by both first- and third-party modules. This would allow the standard library to continue to ship with only exactly what it needs (for example, OpenSSL, SecureTransport and SChannel), but would give those who want to use more esoteric TLS choices (NSS, GnuTLS, mbedTLS, and BoringSSL are some examples) an API that they can implement that will guarantee that complying modules can use the appropriate TLS backend.<br>
<br>
To that end, I’ve composed a draft PEP that would define this API: PEP 543. This draft can be found online here[1], and I have reproduced it below for those who want to reply inline. I should apologise in advance that this PEP is quite large: it is this large because it lays out a substantial proportion of the new code that would be added directly in the PEP. This is to help de-risk the work by showing as much of it up-front during the PEP stage, rather than having it emerge over the implementation process.<br>
<br>
Please note that this proposal is not intended to resolve the current problem pip has with TLSv1.2, and so is not subject to the tight time constraints associated with that problem. That problem will be solved by building a temporary shim into urllib3 (and therefore pip) that can use SecureTransport bindings on the Mac. This proposal is intended as a solution to the more-general problem of supporting different TLS backends in Python, and so is larger in scope and less urgent.<br>
<br>
I should also mention that there will be a tendency to want to make this API all things to all people from the get-go. I’m going to strongly resist attempts to extend this API too much, because each additional bit of API surface makes it harder for us to encourage module authors to conform to this API. I will encourage people to extend this API over time as needed, but to begin with I think it is most important that basic TLS clients and servers can be constructed with this API. More specialised features should be considered future enhancements, rather than being tacked on to this initial PEP.<br>
<br>
Please let me know what you think. I’d like significant feedback from the community before I ask the BDFL to pronounce on this PEP, as this is the kind of change that will affect a large amount of the Python ecosystem. It’s important to me that we minimise the risk to ourselves and the community by getting this as right as possible, and while we can help with that by limiting scope, it’s also true that we need as many eyes as possible.<br>
<br>
Please let me know what you think.<br></blockquote><div><br></div></div>Heh, I guess you must have already caught everyone with a strong opinion about this by way of security-sig :)<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>