On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg <m...@egenix.com> wrote:
> 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 <m...@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. > 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. 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. 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 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. -gps
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
