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

[MRAB]

On 2014-03-25 01:29, Ben Darnell wrote:
> On Mon, Mar 24, 2014 at 4:44 AM, Nick Coghlan <ncoghlan at gmail.com
> <mailto:ncoghlan at gmail.com>> wrote:
>
>
>     On 24 Mar 2014 15:25, "Chris Angelico" <rosuav at gmail.com
>     <mailto: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?
>
>     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 am strongly against allowing downstream distributors that choice.
>   Unless the security-enhanced variant of Python 2.7 quickly and
> completely overtakes all previous versions, we will be creating a
> compatibility problem between the two variants of Python 2.7.  I believe
> that the changes motivating this PEP can be made with minimal
> backwards-incompatibility risk and (if the PEP is accepted) we should
> use all the leverage at our disposal to drive adoption.  The risk is not
> backwards incompatibility, it is ambiguity of what Python 2.7 means. If
> changes under this PEP would result in any distributors rationally
> remaining at Python 2.7.6, then the result of any such changes should be
> labelled Python 2.8.
>
I think that calling it Python 2.8 would be a bad idea for the reasons
that have already been stated.

Perhaps it should just be called Python 2.7 Enhanced Security ("Python
2.7 ES").