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

[Jesse Noller]

> On Mar 23, 2014, at 7:03 PM, Barry Warsaw <barry at python.org> wrote:
> 
>> On Mar 23, 2014, at 08:00 AM, Skip Montanaro wrote:
>> 
>> I'm unclear how this would be better than just biting the bullet and
>> making a 2.8 release. On the one hand, the 2.7.x number suggests
>> (based on the existing release protocol) that it should be a drop-in
>> replacement for earlier 2.7 micro releases. On the other hand, calling
>> it something like "ServerPython" implies that it's not necessary for
>> network client applications, when, if I read the PEP correctly, it
>> most certainly would be.
> 
> It seems to me that the problem the PEP addresses can largely be confined to
> the Python 2.7 standard library and the fact that it's bundled with the
> language.  I want to stick to our no-Python-2.8 pledge, but I wonder if there
> isn't a middle ground where we fork the stdlib into a separate branch, and
> apply security specific changes there.
> 
> Python 2.7.x will always be the "standard stdlib".  We would never release a
> specific Python 2.7 + "security stdlib" release, but downstream developers
> would be able to overlay this forked stdlib on top of the standard one.
> Volunteers or corporate sponsors could distribute binary installers with this
> combination of pure Python 2.7 language + "security enhanced stdlib", and
> Linux distros could do the necessary building and distributing for their own
> platforms if they so desired.
> 
> The trick is what do you call this new combination, how do you invoke it, and
> how do you keep it distinct and independent of the system's standard Python
> 2.7?
> 
> Maybe this is some scent of Python 2.8 by another name, but let's never call
> it Python 2.8.
> 

It seems like this and the fork idea are both jumping through hoops to avoid the inevitable - a 2.7 security release or a 2.8 security only release. Especially as I know nick isn't the only one looking to hire FTEs for this specific work as it's actively hurting service providers/distributions and others.

If we call it a security only release, and scope/review all patches to that it seems that it's pretty clear what the release is for. 

2.x is going to be in the wild for at least another decade as these large legacy codebases are functioning, profitable and dedicating teams of engineers to port them to 3.x doesn't make sense to the business. As new services and things come online we'll see the gradual movement to 3 accelerate especially as people realize clients and service talk better on an interface such as http rather than large monolithic tragedies.


> -Barry
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com