[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

[Chris Angelico]

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