On 3/22/2014 8:55 PM, Nick Coghlan wrote:
Unfortunately, "rudimentary SSL support" is worse than nothing.
I'm going to try to find a way to steal that line and get it into the
PEP. I'm not sure yet if my proposal is the *right* answer, but this
observation gets right to the heart of the problem that actually needs
to be solved.
I'd actually welcome a competing PEP that seriously explored
separating out the relevant parts of the Python 3.4 standard library
as a PyPI project and attempted to tackle the problem by making that
available at least as far back as 2.7 and then just deprecating the
leaking batteries in the 2.7 standard library.
I have a competing proposal that is a variation on yours. First,
restrict attention to 2.7. The problem, as you defined it in the PEP, is
that a) 2.7 is currently not an adequate base for public internet
servers, coupled with b) some companies are determined to continue using
2.x for their servers, and c) condition b) is not going to end in a year
or two. Your proposal is to enhance 2.7 by backporting some indefinite
number of server security features from 3.x to 2.7.
The first problem with this idea is that the result will not be Python
2.7 as currently defined. So lets not break our naming and stability
policy and and engender legitimate objections by labeling Server
Security Python as Python 2.7.z, where z is a single digit. The second
problem is that enhancement will not, I strongly suspect, be a one time
event. So there will need to be several enhancement releases. Producing
a generally enhanced 2.8, 2.9, 2.10, etc, for the next decade would
solve both problems -- but we are adamantly not going to do that.
Instead, I think the PEP should propose a special series of server
enhancement releases that are based on the final 2.7 maintenance release
(2.7.8 or 2.7.9) but which have have a different application-specific
enhancement policy. It would start with something like 'ServerPython
2.7.10', with the numbers moving upward from 10.
I think one justification for this is that if PSF does not sanction such
a series, it will happen anyway, but possibly with different and
incompatible releases from different vendors or distribution families.
As I understand the proposal, a subset of core developers would set the
specification while some commercial group would have to fund it.
The download page for the final 2.7.z maintenance release could say
something like "We recommend that you move to the most recent Python 3
version if at all possible. If you cannot do that and you want to use
Python to run a server on the public internet, we urge you to instead
use the latest version of ServerPython 2.7.1s. This series is based on
Python 2.7.z but has been and will continue to be enhanced with security
features backported from Python 3."
Part of the idea above is that 2.7 development would end or mostly end
after 5 years, the difference being that the last 3 years have not been
restricted only to security bugs. Since security bugs are nearly always
server problems, they would be fixed thereafter in ServerPython. If
ServerPython is kept in the CPython repository, it would be a separate
branch. I would, of course, also need enhancements needed to build
sensibly on current systems. On Windows, for instance, it would be built
with a current compiler.
There are still details to be filled in or altered, but this is my
general idea.
--
Terry Jan Reedy
_______________________________________________
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
