On 21.06.2014 12:51, Nick Coghlan wrote: > On 21 June 2014 20:27, M.-A. Lemburg <m...@egenix.com> wrote: >> With PEP 466 and the constant flow of OpenSSL security fixes >> which are currently being handled via Python patch level releases, >> we will soon reach 2.7.10 and quickly go beyond that (also see >> http://bugs.python.org/issue21308). >> >> This opens up a potential backwards incompatibility with existing >> tools that assume the Python release version number to use the >> "x.y.z" single digit approach, e.g. code that uses sys.version[:5] >> for the Python version or relies on the lexicographic ordering >> of the version string (sys.version > '2.7.2'). > > Such code has an easy fix available, though, as sys.version_info has > existed since 2.0, and handles two digit micro releases just fine. The > docs for sys.version also have this explicit disclaimer: "Do not > extract version information out of it, rather, use version_info and > the functions provided by the platform module."
I don't think that's a good argument. Of course, there are better ways to figure out the version number, but fact is, existing code, even in the stdlib, does use and parse the sys.version string version. During Python's lifetime, we've always avoided two digit version numbers, so people have been relying on this, even if it was never (AFAIK) documented anywhere. > 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. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 21 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-06-17: Released eGenix PyRun 2.0.0 ... http://egenix.com/go58 2014-06-09: Released eGenix pyOpenSSL 0.13.3 ... http://egenix.com/go57 2014-07-02: Python Meeting Duesseldorf ... 11 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ 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
