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

Georg Brandl g.brandl at gmx.net
Tue Mar 25 09:21:16 CET 2014

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

More information about the Python-Dev mailing list