[Python-Dev] Supported versions of OpenSSL

Mon Aug 29 15:31:07 EDT 2016

On 29.08.2016 18:33, Cory Benfield wrote:
> 
>> On 29 Aug 2016, at 04:09, M.-A. Lemburg <mal at 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?

Ubuntu 14.04 is a widely deployed system and newer Python version
should run on such widely deployed systems without having to
replace important vendor maintained system libraries such as
OpenSSL.

Python 3.7 starts shipping around June 2018 (assuming the 18 month
release cycle). Ubuntu 14.04 EOL is April 2019, so in order to
be able to use Python 3.7 on such a system, you'd have to upgrade
to a more recent LTS version 10 months before the EOL date (with
all the associated issues) or lose vendor maintenance support and
run with your own copy of OpenSSL.

OTOH, the situations isn't all that bad: people on such systems
will likely not go straight for the 3.7.0 release of Python, but
instead wait for 3.7.2+ for the dust to settle.

> 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 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.
> 
> 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?
> 
> 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.

Sure, but Ubuntu will continue to support OpenSSL 1.0.1
until 2019, backporting important security fixes as necessary and
that's what's important.

It's unfortunate that Python has to rely on a 3rd party library
for security, but we should at least make sure that our users
can rely on OS vendor support to keep the lib up to date with
security fixes.

On 29.08.2016 10:24, Christian Heimes wrote:
> By the way I knew that something like this would come up from you.
> Thank you that you satisfied my expectation. :p

Sure, I want Python to be used on as many systems as possible,
both in terms of architecture and OS. The more the better.
If we don't have to drop support early, why should we ?

>> BTW: Are there any features in 1.0.2 that we need and would warrant
>> dropping support for 1.0.1 earlier than Ubuntu 14.04 LTS ?
>
> Yes, there are features I want to use, e.g. proper hostname
> verification. Python's post-handshake verification is a hack and leads
> to information disclosure.

This doesn't sound like a feature worth breaking compatibility
to me.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Aug 29 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

   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/
                      http://www.malemburg.com/