[Python-Dev] Python 2.7 patch levels turning two digit

[Ned Deily]

In article <53A5B995.6040802 at egenix.com>,
 "M.-A. Lemburg" <mal at egenix.com> wrote:
> > Making it harder to tell whether or not someone's Python installation
> > is affected by an OpenSSL CVE is also an undesirable outcome. On a
> > Linux distro, folks will check the distro package database directly
> > for the OpenSSL version, but on Windows, no such centralised audit
> > mechanism is available by default. With OpenSSL statically linked,
> > Python versions can just be mapped to OpenSSL versions (so, for
> > example, 2.7.7 has 1.0.1g)
> 
> I have to disagree here as well :-)
> 
> If people cannot upgrade to a higher patch level for whatever
> reason (say a patch level release introduced some other bugs),
> but still need to upgrade to the current OpenSSL version, they'd
> be stuck if we continue to bind the Python version number to
> some OpenSSL release version.
> 
> We should definitely make it possible to address OpenSSL
> bugs without having to upgrade Python and it's not hard to
> do: just replace the static binding with dynamic binding
> and include the two OpenSSL DLLs with the Windows installer.
> 
> People can then drop in new versions of those DLLs
> as needed, without having the core devs do a complete
> new release every time someone finds a new problem those
> libs. Security libs simply have a much higher release
> rate (if they are well maintained) than most other
> software.

I agree that with Nick and Barry that, due to the extended support 
period for 2.7, we have no choice but to bite the bullet and deal with 
micro levels exceeding 9.  On the other hand, it would also be good to 
be better able to deal with third-party library revisions that only 
affect the Windows or OS X binary installers we supply.  I don't know 
that we've ever had a process/policy in place to do that, certainly not 
recently.  Even for statically linked libraries, we presumably could 
supply replacement re-linked files or even carefully repacked installers 
with the updated files.  This might be something to discuss and add to 
PEP 101 or a new PEP.

Up to now, this hasn't been a major concern since there have usually 
been other reasons to do full releases as well, e.g. source regressions.  
Given the still relatively high churn rate for changes going into 2.7 
and the growing distance between the 2.7 and 3.x code bases (among other 
things, leading to more frequent inadvertent backporting errors), we'll 
probably need to keep making relatively frequent 2.7 releases unless we 
can further slow down the 2.7 change rate.

-- 
 Ned Deily,
 nad at acm.org