In article <53a5b995.6040...@egenix.com>, "M.-A. Lemburg" <m...@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, n...@acm.org _______________________________________________ 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
