On Mon, 29 Aug 2016 at 09:34 Cory Benfield <c...@lukasa.co.uk> wrote:
> > > On 29 Aug 2016, at 04:09, M.-A. Lemburg <m...@egenix.com> wrote: > > > > On 28.08.2016 22:40, Christian Heimes wrote: > >> ... > >> I like to reduce the maintenance burden and list of supported OpenSSL > >> versions ASAP. OpenSSL has deprecated 0.9.8 and 1.0.0 last year. 1.0.1 > >> will reach EOL by the end of this year, > >> https://www.openssl.org/policies/releasestrat.html . However OpenSSL > >> 0.9.8 is still required for some platforms (OSX). > >> ... > >> For upcoming 3.6 I would like to limit support to 1.0.2+ and require > >> 1.0.2 features for 3.7. > >> ... > > > > Hmm, that last part would mean that Python 3.7 will no longer compile > > on e.g. Ubuntu 14.04 LTS which uses OpenSSL 1.0.1 as default version. > > Since 14.04 LTS is supported until 2019, I think it would be better > > to only start requiring 1.0.2 in Python 3.8. > > Can someone explain to me why this is a use-case we care about? > > The nature of a stable distribution is that all the packages are > guaranteed to work together. Once you start compiling your own software, > you are out in the cold: you are no longer covered by that guarantee. Why, > then, should someone compiling a version of Python that was barely > conceived when Ubuntu 14.04 was released expect that they can compile it > from source using only dependencies available in their mainline > distribution? > I also agree with this view. If you're on an LTS then you should expect everything that comes with the LTS to work, not new software that you pulled forward unless your OS distributor supports it, e.g. RHEL collections. > > I absolutely understand wanting to support Ubuntu 14.04 for any release of > Python that already compiles on Ubuntu 14.04: that makes sense. But new > releases should not be shackled to what is in LTS releases of operating > systems. If it were, a more coherent argument would be that we cannot drop > 0.9.8 support in any Python released before the middle of 2017 because RHEL > 5 ships it, and we will not be able to require OpenSSL 1.0.2 until almost > 2021 because RHEL 6 ships 1.0.1. After all, why does Ubuntu 14.04 get > privileged over RHEL? Both are supported LTS releases, after all. > No one gets special privileges beyond someone funding a core dev to put into the effort to support a platform that won't shackle others. > > I don’t believe that the Python dev team has ever promised that future > versions of Python will compile on a given LTS release. Am I mistaken? > No, literally the only support promise we make along these lines is that we will support Windows versions that are still in extended support: https://www.python.org/dev/peps/pep-0011/#id10 , and that promise only works due to Windows not being a moving target in terms of backwards-compatibility. > > While I’m here, I should note that Ubuntu 14.04 goes EOL in 2019, while > OpenSSL 1.0.1 loses support from upstream at the end of this year, which is > probably a good reason to stop supporting it in new Python versions. > OpenSSL 1.0.0 and 0.9.8 are already unsupported by upstream. > I agree w/ Christian's proposal of matching what OpenSSL upstream supports when releasing new versions of CPython. I don't see how supporting outdated security code is good for anyone involved.
_______________________________________________ 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
