[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
Chris Angelico
rosuav at gmail.com
Thu Jun 1 05:50:22 EDT 2017
More information about the Python-Dev mailing list
Thu Jun 1 05:50:22 EDT 2017
- Previous message (by thread): [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
- Next message (by thread): [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Jun 1, 2017 at 7:23 PM, Antoine Pitrou <antoine at python.org> wrote: >> Do you also disagree on the need of the need of the PEP 546 >> (backport) to make the PEP 543 (new TLS API) feasible in practice? > > Yes, I disagree. We needn't backport that new API to Python 2.7. > Perhaps it's time to be reasonable: Python 2.7 has been in bugfix-only > mode for a very long time. Python 3.6 is out. We should move on. But it is in *security fix* mode for at least another three years (ish). Proper use of TLS certificates is a security question. How hard would it be for the primary codebase of Requests to be written to use a C extension, but with a fallback *for pip's own bootstrapping only* that provides one single certificate - the authority that signs pypi.python.org? The point of the new system is that back-ends can be switched out; a stub back-end that authorizes only one certificate would theoretically be possible, right? Or am I completely misreading which part needs C? ChrisA
- Previous message (by thread): [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
- Next message (by thread): [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list