[Python-Dev] Python 2.7 patch levels turning two digit (original) (raw)

Ned Deily nad at acm.org
Sat Jun 21 20:47:08 CEST 2014

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

More information about the Python-Dev mailing list