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

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