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

[Donald Stufft]

On Mar 23, 2014, at 8:31 PM, Jesse Noller <jnoller at gmail.com> wrote:

> 
> 
>> 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
> _______________________________________________
> 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/donald%40stufft.io

I agree, the bulk of the alternative suggestions feel more like trying to
adhere to a policy for policy’s sake rather than actually figure out what is
best for the users.

Adding new APIs to 2.7 feels to me like a pretty backwards compatible thing to
be honest. The biggest contenders are things like SSLContext and match_hostname.
The PEP still says things must be backwards compatible so we can't change
existing APIs in a way that the backported things aren't opt in. I mean how
likely is it that there is code out there relying on the fact that SSLContext
doesn't exist other than as a detection to determine if they can use SSLContext?

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140323/3798fba6/attachment.sig>