[Python-Dev] Supported versions of OpenSSL

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

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/