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

R. David Murray rdmurray at bitdance.com
Sun Mar 23 01:48:46 CET 2014


On Sun, 23 Mar 2014 01:01:38 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 23 Mar 2014 07:11:07 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
> > This PEP does *not* grant any general exemptions to the usual backwards
> > compatibility policy for maintenance releases. Instead, it is designed
> > to make it easier to provide more "secure by default" behaviour in future
> > feature releases, while still limiting the risk of breaking currently
> > working software when upgrading to a new maintenance release.
> 
> But enforcing "secure by default" can by construction break backwards
> compatibility, which is the very reason we are so conservative with
> such changes.

Yeah, I couldn't figure out what this paragraph meant.  What does
backporting features in maintenance releases have to do with making
feature releases secure by default?

If we are not relaxing the backward compatibility rules we can't do secure
by default changes in a maintenance release...and if we don't do that,
thinking that very much legacy software is going to get upgraded to
use the new "more secure" capabilities is, I suspect (but cannot prove,
obviously) mostly wishful thinking.  An exception might be be commercial
packages, but even there I wouldn't bet very many bucks.  It seems to
me that shops who are being security concious enough to be candidates
for modifying currently deployed packages to be more secure are also
likely to have already addressed the security issues in some other way.

Now, requests and other libraries could use these new features, and
since they have faster release cycles, they could presumably make the
increased security be the default sooner.  So that's what I see as the
argument in favor...but it is a much narrower impact area than "most
python software that uses ssl", and certainly doesn't cover poplib,
smtplib, etc.

But perhaps I am being overly cynical.

Regardless, like Martin, I prefer to focus on Python3.

--David


More information about the Python-Dev mailing list