On 30 August 2016 at 02:33, 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?
I can think of a few key cases where it's potentially going to have an impact: - availability of new Python versions in public PaaS environments - availability of new Python versions in free-for-open-source public CI services - the "maximum supported Python version" for iterations of the manylinux project Fortunately, public PaaS providers and public CI providers tend to fall into the "upgrade Linux when new LTS releases are available, not when the old ones are about to lose support" category, so a policy of targeting the latest LTS releases (perhaps with a "more than 12 months old" caveat) rather than the oldest still commercially supported ones should be sufficient on that front (if the LTS vendors decide they'd like us to change that policy, they always have the option of funding it accordingly). Currently, that means: - Debian 8 - Ubuntu 16.04 (or 14.04 with the "12 months old" caveat) - RHEL/CentOS 7 And then trusting that supporting those will also cover other Linux distros that aren't as directly involved in upstream CPython development. That means the main potential source of problems I see here is the manylinux project, but fortunately that concern was accounted for by explicitly excluding OpenSSL from the defined portable ABI: https://www.python.org/dev/peps/pep-0513/#security-implications So it's already a manylinux requirement that anyone wanting to use ssl in a portable way needs to either use the standard library module, or else something like PyOpenSSL (which bundles its own copy, independent of what the system provides) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
