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

[Terry Reedy]

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