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

[Nick Coghlan]

On 25 March 2014 12:25, MRAB <python at mrabarnett.plus.com> wrote:
> 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").

The PEP currently calls the proposed unmodified fork of 2.7 "Python
2.7 with Legacy SSL". I suspect we could potentially ask the PSF to
enforce that from a trademark perspective (that is, redistributors
wouldn't be allowed to call versions with the legacy infrastructure
"Python 2.7", they'd have to include the "with Legacy SSL" qualifier -
that would also encompass all redistributions of 2.7.6 and below).

I'm actually personally OK with just making vendors do all the work if
they're really so worried about a slightly increased chance of
undetected regressions that they prefer to keep using older SSL
infrastructure. I think persisting with the old SSL infrastructure for
too much longer would be a fundamentally bad idea, so I don't mind at
all making it more difficult for downstream redistributors to do so.

As Ben notes, allowing them this option increases the chance of
confusion about what "Python 2.7" means, and once an upgrade Python
2.7 release was published, the "Python 2.7 with Legacy SSL" moniker
would apply just as well to Python 2.7.6 and earlier as it would to a
hypothetical additional branch that would impose an ongoing
maintenance burden upstream.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia