[Python-Dev] PEP 543: A Unified TLS API for Python
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. Cory [1]: https://www.python.org/dev/peps/pep-0543/ — PEP: 543 Title: A Unified TLS API for Python Version: $Revision$ Last-Modified: $Date$ Author: Cory Benfield , Christian Heimes Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17-Oct-2016 Python-Version: 3.7 Post-History: 11-Jan-2017, 19-Jan-2017, 02-Feb-2017, 09-Feb-2017 Abstract This PEP would define a standard TLS interface in the form of a collection of abstract base classes. This interface would allow Python implementations and third-party libraries to provide bindings to TLS libraries other than OpenSSL that can be used by tools that expect the interface provided by the Python standard library, with the goal of reducing the dependence of the Python ecosystem on OpenSSL. Rationale = In the 21st century it has become increasingly clear that robust and user-friendly TLS support is an extremely important part of the ecosystem of any popular programming language. For most of its lifetime, this role in the Python ecosystem has primarily been served by the `ssl module`_, which provides a Python API to the `Ope
Re: [Python-Dev] [Python-checkins] [python/cpython] 4538dd: Fix bpo-29528 Use a secure variable to stop spam (...
On Feb 11, 2017, at 08:11 PM, Andrew M. Kuchling wrote: >Are we planning to include the diffs in python-checkins e-mail, or are >they gone for good? > >(While they made the list's messages and digests larger, I liked >having the diffs because you could page through them to see what >changes were made without having to go through to another site.) Yep, this was recently discussed and I think the plan is to bring them back for python-checkins, but that it's not possible to enable them on PRs due to GH limitations. Cheers, -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] [python/cpython] 4538dd: Fix bpo-29528 Use a secure variable to stop spam (...
On Mon, 13 Feb 2017 at 07:10 Barry Warsaw wrote: > On Feb 11, 2017, at 08:11 PM, Andrew M. Kuchling wrote: > > >Are we planning to include the diffs in python-checkins e-mail, or are > >they gone for good? > > > >(While they made the list's messages and digests larger, I liked > >having the diffs because you could page through them to see what > >changes were made without having to go through to another site.) > > Yep, this was recently discussed and I think the plan is to bring them back > for python-checkins, but that it's not possible to enable them on PRs due > to > GH limitations. > Serhiy asked about it and I said that the email integration we are using from GitHub doesn't allow for customizing the email it sends out beyond how is listed in the From line. If people find a different integration that they want to use for sending email then that can be set up. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] [python/cpython] 4538dd: Fix bpo-29528 Use a secure variable to stop spam (...
--Berker On Mon, Feb 13, 2017 at 8:54 PM, Brett Cannon wrote: > > > On Mon, 13 Feb 2017 at 07:10 Barry Warsaw wrote: >> >> On Feb 11, 2017, at 08:11 PM, Andrew M. Kuchling wrote: >> >> >Are we planning to include the diffs in python-checkins e-mail, or are >> >they gone for good? >> > >> >(While they made the list's messages and digests larger, I liked >> >having the diffs because you could page through them to see what >> >changes were made without having to go through to another site.) >> >> Yep, this was recently discussed and I think the plan is to bring them >> back >> for python-checkins, but that it's not possible to enable them on PRs due >> to >> GH limitations. > > > Serhiy asked about it and I said that the email integration we are using > from GitHub doesn't allow for customizing the email it sends out beyond how > is listed in the From line. If people find a different integration that they > want to use for sending email then that can be set up. I wrote a webhook that includes diffs: An example output can be seen at https://github.com/python/core-workflow/issues/24#issuecomment-279162079 Since it listens all 'push' events, it's possible to catch all commits and send them to python-checkins. --Berker ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Heads-up, I've rejoined
Some of the older Pythonistas will remember my previous time on this list, and possibly that I faded away quietly under time pressure from other projects and the whole being-famous nonsense. I'm back, for now primarily to listen. I have some questions about the future direction of Python which I'll bring up when I have time for the vigorous discussion that will certainly ensue. -- >>esr>> ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Update on labels to be used on GitHub
We now have two sets of labels for representing cherry-picking statuses: "backport to N.M" and "cherry-pick for N.M". The former are to help keep track of what branches a PR should be cherry-picked *to* and can be removed once the PR for a cherry-pick has been created (you can add a comment like "cherry-picked from GH-NN" to make the link between the PRs)*.* The latter labels are to signify that the PR is a cherry-pick *itself*. As with all aspects of the new GitHub workflow, we will give this a solid try for about a month and then we can re-evaluate whether we like this approach or want a more traditional prefix format in the title to represent the same thing. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update on labels to be used on GitHub
2017-02-13 21:08 GMT+01:00 Brett Cannon : > We now have two sets of labels for representing cherry-picking statuses: > "backport to N.M" and "cherry-pick for N.M". The former are to help keep > track of what branches a PR should be cherry-picked to and can be removed > once the PR for a cherry-pick has been created (you can add a comment like > "cherry-picked from GH-NN" to make the link between the PRs). The first time I looked at the "backport to 3.6" flag, I understood that the change was written on the 3.6 branch and asked to rebase the change on 3.6. If I was confused, I'm sure that someone else will be confused as well :-) What do you think of renaming the label to "need 3.6 backport" (or "need backport to 3.6")? Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
