[Python-Dev] Supported versions of OpenSSL

[Christian Heimes]

On 2016-08-29 21:31, M.-A. Lemburg wrote:
> 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.

"Widely deployed" is true for a lot of old operating systems including
Windows XP.

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

Why would you deploy an unsupported Python version on a LTS release? Why
should compatibility be our concern?

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

I see an easy solution here: either pay or make Canonical backport all
required features to OpenSSL 1.0.1. </sarcasm>

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

No, it is a good thing that we can rely on 3rd party libraries for
security. Crypto and security is not our domain. It is incredible hard
to develop and maintain crypto code. Also my proposal enforces OS
vendors to supply up to date OpenSSL versions.

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

MAL, I don't like your attitude. It feels like you want me and other
contributors to waste time on this topic. That is not how this
discussion is going to end. If *you* want to keep support for outdated
OpenSSL versions, than it is *your* responsibility and *your* time. You
cannot and will not put this burden on me.

Python is running out of developers with OpenSSL expertise. It's Alex,
Antoine, Benjamin, Victor and me. Antoine and me haven't been active for
a while. Victor and Benjamin are mostly working on other topics. As far
as I can judge Alex, he rather works on PyCA than CPython stdlib.

I'm both interested and willing to improve Python's ssl stack, and I'm
going to do this in my own free time. Yes, I'm working for Red Hat's
security engineering, but I'm not getting paid to work on Python (except
for a couple of hours now and then when a bug is relevant for my daily
work). I will only contribute improvements and fixes on my own terms,
that means I'm not going to waste my time with outdated versions. In my
opinion it is more than reasonable to ditch 1.0.1 and earlier.

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

It does.

Christian