[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements (original) (raw)
Chris Angelico rosuav at gmail.com
Mon Mar 24 10:02:21 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 Mon, Mar 24, 2014 at 7:44 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
On 24 Mar 2014 15:25, "Chris Angelico" <rosuav at gmail.com> wrote:
As has already been pointed out, this can already happen, but in an ad-hoc way. Making it official or semi-official would mean that a script written for Debian's "Python 2.7.10" would run on Red Hat's "Python 2.7.10", which would surely be an advantage. And having it break on the official Windows and Mac OS X binaries would benefit end users, how?
It wouldn't. And if python.org doesn't publish a Windows binary, then either the exact same thing will happen, or there'll be one unofficial SEPython-like build. With only a semi-official SEPython 2.7.10, there could still be installers for all platforms - if nothing better, a two-stage installer that fires off the unchanged one and then plonks its own files elsewhere.
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.
That's how it'd be with an official 2.7 security-enhanced release, and that would be fine. But even not going that far would have its benefit; as long as there's a clear definition of what "SEPython 2.7.10" (or whatever it's called) is, a source-only release of those files would at least help to unify what would otherwise be a mess. But going the whole way and making a binary installer for an enhanced-security Python would definitely unify it a lot more.
ChrisA
- 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 ]