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

[Nick Coghlan]

On 14 February 2017 at 00:26, Cory Benfield <cory at lukasa.co.uk> wrote:

> All,
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Please let me know what you think.
>

Heh, I guess you must have already caught everyone with a strong opinion
about this by way of security-sig :)

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170224/c677ef9b/attachment.html>