[Python-Dev] Supported versions of OpenSSL

Wed Aug 31 04:31:12 EDT 2016

On 31.08.2016 01:55, Gregory P. Smith wrote:
> On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg <mal at egenix.com> wrote:
>>> On 29.08.2016 22:16, Christian Heimes wrote:
>>> 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.
>>
> 
> We have. The proposal now stands at: We're free to ditch 1.0.1 and earlier
> support in 3.7 as soon as we have a need for a 1.0.2 specific API.
> 
> There don't seem to be any important negative consequences of doing so.

Uhm, what about not being able to run Python unless you are willing
to stop taking benefit of OS vendor supplied OpenSSL security
fixes ?

In all this discussion I have yet to find a compelling security
relevant argument for using an 1.0.2 API which is so important
that we cannot make this optional at runtime.

The only argument Christian reported was this one:

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

Regarding that argument: hostname validation can be done
in 1.0.1 by providing a verification hook handler. That's
intended and by design, not a hack. 1.0.2 comes with
support for hostname validation making this a little easier
(you still have to set this up, though).

So essentially, the only argument so far has been that
we can remove some support code and let 1.0.2 take care of
this.

That's a maintenance argument, not a security one. And the
code in question has been rather stable, so it doesn't add
much maintenance overhead:

https://hg.python.org/cpython/annotate/default/Lib/ssl.py#l195

For dropping Python support on older platforms, I'd expect to
at least see an argument such as: 1.0.1 has a security flaw
which cannot be addressed by design (e.g. a missing crypto
feature which is essential for working with modern SSL
servers).

>> 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.
> 
> While technically true, the ssl module is required to fetch and install
> software via pip which for casual users means it is essential. People can
> always operate without it if they are willing to download and build the
> libraries they need manually.
>
>> 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.
>>
> 
> Not important. That isn't something we need to worry about. Compiling a new
> libssl is easy.  People using systems that are 4+ years old by the time 3.7
> comes out who expect new software to compile and just work are expecting
> too much.

Perhaps, but industry OSes are not upgraded that often, so it's
not unusual to run into a system where you'd like to get Python
working on an LTS OS version which is still maintained but doesn't
use the latest and greatest software versions.

> I find that users of such systems either use only what their distro itself
> supplies (ie: ancient versions at that point) or are fully comfortable
> building any dependencies their own software needs. If they are comfortable
> building a CPython runtime in the first place, they should be comfortable
> building required libraries. Nothing new there.

Why do you assume that people will compile their own CPython
on such systems ? It's well possible, and probably more likely,
that they want to run a binary version of the application on
such a platform, only to find that it doesn't run because of
a missing OpenSSL 1.0.2 API (the libssl.so.1.0 will still be
available, but not expose the requested API - the lib version
of OpenSSL did not change between 1.0.1 and 1.0.2).

>> 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 ?
>>
> 
> In general, conditional compilation complicates code and adds a maintenance
> burden. The sooner we can ditch older versions, the cleaner and easier to
> maintain our code is.

I think we need to find the right balance here. A few lines of
conditional code vs. Python not running on a system at all.

And just to be clear, since some people appear to think that
I want to make them work for me for free (something I find a bit
bizarre given how much time I have invested in Python development -
you are benefiting from the code I've written just as much as
I am from the code you have written):

We are using our own egenix-pyopenssl package which comes with
OpenSSL 1.0.2 and we do take on the challenge to support this
on multiple platforms, including older ones. So the argument
is somewhat pointless.

I am thinking of Python users out there who are running on LTS
OS releases simply because their IT doesn't let them run anything
else. If we want to cut them off, we should have compelling arguments
to do so. IMO, the arguments brought up so far are not good
enough.

-- 
Marc-Andre Lemburg
eGenix.com

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