[Python-Dev] Supported versions of OpenSSL (original) (raw)

M.-A. Lemburg mal at egenix.com
Tue Aug 30 16:07:55 EDT 2016

On 29.08.2016 22:16, Christian Heimes wrote:

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

That was not my point. It's unfortunate that Python depends on a library which is inevitably going to need updates frequently, and which then may have the implication that Python won't compile on systems which don't ship with more recent OpenSSL libs - even if your application doesn't even need ssl at all.

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.

Please reread what I suggested: to postpone the switch to require OpenSSL 1.0.2 by one Python release version. And in my reply I then put this into more context, saying that your schedule will likely work out.

Postponing this should not introduce more work for anyone; if you'd like to add support for 1.0.2 feature early this can also easily be done by making such support optional depending on which OpenSSL lib Python is compiled against. This takes a few #ifdefs, nothing more.

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.

I want you to consider the consequences of doing this carefully.

Crypto is important to have, but at the same time it's not essentially for everything you do in Python, e.g. you can easily run data analysis scripts or applications without ever touching the ssl module.

Yet, a move to require OpenSSL 1.0.2 for Python 3.7 will make it impossible to run such apps on systems that still use OpenSSL 1.0.1, e.g. Ubuntu 14.04 or CentOS 7.

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

Why not make the 1.0.2 and 1.1.0 support optional as we do in so many other situations for various systems and libs ?

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Experts (#1, Aug 30 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/

More information about the Python-Dev mailing list