[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements (original) (raw)
Cory Benfield cory at lukasa.co.uk
Mon Mar 24 10:28:08 CET 2014
- Previous message: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
- Next message: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 24 March 2014 08:44, Nick Coghlan <ncoghlan at gmail.com> wrote:
The position I am coming to is that the "enhanced security" release should be the default one that we publish binary installers for, but we should also ensure that downstream redistributors can easily do "Python 2.7 with legacy SSL" releases if they so choose. I'm happier forcing end users to rely on a redistributor to opt in to a lower security option than I am to knowingly publish too many additional releases with network security infrastructure that is (at best) rapidly approaching its use by date.
I'm with you here Nick, the default should really be "Python 2.7 with working TLS", not "Python 2.7 with broken TLS" (my only-slightly tongue-in-cheek proposed names for the releases). My concern with having Chris' proposal of an opt-in SEPython release is about discovery. I suspect most people will never find out about the SEPython release, meaning that most people will remain on insecure Python 2.7 distributions. If that happens, requests is essentially required to continue to support our current TLS model for 2.7 for as long as we support 2.7, and this PEP would give us no benefit at all. We're obviously not the only stakeholder here, but it's worth noting.
Cory
- Previous message: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
- Next message: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]