[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
Barry Warsaw
barry at python.org
Mon Mar 24 01:03:12 CET 2014
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.
-Barry
More information about the Python-Dev
mailing list