On Tue Mar 25 2014 at 4:21:51 AM, Georg Brandl <g.bra...@gmx.net> wrote:
> 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.
>
Or if this is such a big deal we start with 2.7.6 and not postpone until
2.7.10 (which I guess could happen immediately after 2.7.9 and have nothing
more than the upgraded modules).
People have been making grandiose statements about how the security of the
internet is hampered by Python 2.7 in this discussion. If these statements
are actually not over-stated then we should do the fix sooner *and* add the
incentive people to switch over by getting more bug fixes. It's not like
Python 2.7 is getting a ton of fixes at this point anyway.
>
> > 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).
>
As long as we make it clear we have chosen to change our
backwards-compatibility guarantees in the name of security and have a link
to the last backwards-compatible release then I agree as well.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
