[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7 (original) (raw)
Chris Angelico rosuav at gmail.com
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 ]