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

[Georg Brandl]

Am 25.03.2014 08:51, schrieb Nick Coghlan:

>> 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 don't know.  It still feels like a source of confusion all round to
have two different (C)Pythons not distinguished by version number.

I haven't followed all of this thread, so forgive me if this suggestion
has come up already:

Since we know the EOL of 2.7, can't we say there won't be any more "non-secure"
bugfix releases than up to 2.7.9, and the namespace 2.7.10 (yeah I know, but
still way better than 2.8) and above is free for the "new SSL" versions.

This also works from a version requirement point of view: if you require Python
>= 2.7.10 you know you'll get the new features.  If you don't, you shouldn't
be using (or carefully checking) the new opt-in features.

> 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.

I agree, if no other solution can be found we should err on the secure
side (as opposed to the safe side).

Georg