On Mar 23, 2014, at 8:31 PM, Jesse Noller <jnol...@gmail.com> wrote:
> > >> On Mar 23, 2014, at 7:03 PM, Barry Warsaw <ba...@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@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@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
