Re: [Python-Dev] Supported versions of OpenSSL
I think it's time for this thread to stop as everyone seems to be talking in circles. Christian said he's going to write a PEP so let's wait for that before discussing this any further so we have a concrete proposal to focus around. On Wed, 31 Aug 2016 at 05:04 Nick Coghlanwrote: > On 31 August 2016 at 20:20, M.-A. Lemburg wrote: > > ... which would then mean: Python's compatibility roadmap will > > be dictated by OpenSSL. > > > > I won't buy into that, sorry. Crypto is a helper in certain > > situations, it's not what Python is all about. We should not > > let OpenSSL dictate how and when we deprecate platforms or > > OS versions. > > It won't dictate general support for those platforms, it will dictate > support for the *ssl module* on those platforms. If someone isn't > making secure network connections from Python, things will work fine. > If a redistributor is stepping in to provide the assertion that the > network connection is secure despite our upstream misgivings, things > will work fine. > > Connections will only fail in cases where neither we nor a > redistributor are prepared to make the assertion that a requested > secure network connection will actually be secure. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > 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/brett%40python.org > ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 31.08.2016 14:02, Nick Coghlan wrote: > On 31 August 2016 at 20:20, M.-A. Lemburgwrote: >> ... which would then mean: Python's compatibility roadmap will >> be dictated by OpenSSL. >> >> I won't buy into that, sorry. Crypto is a helper in certain >> situations, it's not what Python is all about. We should not >> let OpenSSL dictate how and when we deprecate platforms or >> OS versions. > > It won't dictate general support for those platforms, it will dictate > support for the *ssl module* on those platforms. If someone isn't > making secure network connections from Python, things will work fine. > If a redistributor is stepping in to provide the assertion that the > network connection is secure despite our upstream misgivings, things > will work fine. > > Connections will only fail in cases where neither we nor a > redistributor are prepared to make the assertion that a requested > secure network connection will actually be secure. Yes, you can view it that way. Your car works, but access to fuel is severely limited ;-) The way things are developing around Python, if pip doesn't work, your Python installation cannot be considered working. Hmm, perhaps pip ought to fallback to curl or wget if there's no ssl module. Or we move away entirely from HTTPS and use properly signed Python packages - ah, nevermind, it's not the first time that have different views than many other core devs. That's fine. -- 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/ ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 31 August 2016 at 20:20, M.-A. Lemburgwrote: > ... which would then mean: Python's compatibility roadmap will > be dictated by OpenSSL. > > I won't buy into that, sorry. Crypto is a helper in certain > situations, it's not what Python is all about. We should not > let OpenSSL dictate how and when we deprecate platforms or > OS versions. It won't dictate general support for those platforms, it will dictate support for the *ssl module* on those platforms. If someone isn't making secure network connections from Python, things will work fine. If a redistributor is stepping in to provide the assertion that the network connection is secure despite our upstream misgivings, things will work fine. Connections will only fail in cases where neither we nor a redistributor are prepared to make the assertion that a requested secure network connection will actually be secure. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 31 August 2016 at 19:33, M.-A. Lemburgwrote: > On 31.08.2016 10:43, Antoine Pitrou wrote: >> On Wed, 31 Aug 2016 10:31:12 +0200 >> "M.-A. Lemburg" wrote: >>> >>> 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. >> >> There is a solution nowadays, which is to use Anaconda (or Miniconda). > > Sure, or use ActivePython or eGenix PyRun :-) > > But is that really what we want to tell people ? I'm personally entirely comfortable with it, as large organisations running community supported code without investing back into the upstream community accordingly is currently a major problem in the Python ecosystem - many technical folks find it easier to reach out to the open source community for better support than they do to go into battle with their own Finance departments to argue for appropriate investment in managing their supply chain. Unfortunately, while that's an entirely understandable reaction to an all too common form of organisational dysfunction, it's also a major contributor to community volunteer burnout. Accordingly, we need more of these organisations to either fund paid upstream development directly (e.g. by assigning their own staff to do it or hiring existing core developers), or else for them to start paying commercial redistributors, and making it clear that they expect those redistributors to fund ongoing upstream development and maintenance activities on their behalf. For folks that are already paying commercial redistributors, we need them to be asking pointed questions of their support managers, like "We're paying you for commercial CPython support, so why don't you have anyone assigned to work on it full time?" Adopting that strategy isn't without its risks - some organisations may react by banning the use of Python entirely and go looking for a less assertive community (or one with better established funding sources), rather than finding ways to pay for suitable infrastructure support arrangements. However, hopefully folks within such organisations will understand their political environment well enough to know whether or not they need to stay under the executive radar. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 31.08.2016 12:05, Christian Heimes wrote: > This was my last reply to your mails on this topic. It's clear to me > that you are not open to Cory's, Nick's or my arguments and that you > won't change your position. More replies are just a waste of my limited > time. I *am* open to arguments, but so far I have not seen a compelling one which strikes the right balance. And if you have read my replies, I'm only suggesting to postpone the switch to 1.0.2 by one release and even there I said that it's not all that dramatic if this doesn't happen due to the way the timelines for 3.6 and 3.7 work. What I am seriously worried about, is the next step ... > Instead I'm going to focus on a PEP to define OpenSSL support and to > auto-deprecate unsupported OpenSSL versions. The PEP is a very high > chance to get accepted. Everybody except you support the plan. ... which would then mean: Python's compatibility roadmap will be dictated by OpenSSL. I won't buy into that, sorry. Crypto is a helper in certain situations, it's not what Python is all about. We should not let OpenSSL dictate how and when we deprecate platforms or OS versions. -- 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/ ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 2016-08-30 18:00, Antoine Pitrou wrote: > On Sun, 28 Aug 2016 22:40:11 +0200 > Christian Heimeswrote: >> >> Here is the deal for 2.7 to 3.5: >> >> 1) All versions older than 0.9.8 are completely out-of-scope and no >> longer supported. >> >> 2) 0.9.8 is semi-support. Python will still compile and work with 0.9.8. >> However we do NOT promise that is secure to run 0.9.8. We also require a >> recent version. Patch level 0.9.8zc from October 2014 is reasonable >> because it comes with SCSV fallback (CVE-2014-3566). >> >> 3) 1.0.0 is irrelevant. Users are either stuck on 0.9.8 or are able to >> upgrade to 1.0.1+. Let's not support it. >> >> 4) 1.0.1 is discouraged but still supported until its EOL. >> >> 5) 1.0.2 is the recommend version. >> >> 6) 1.1 support will be added by #26470 soon. >> >> 7) LibreSSL 2.3 is supported but with a slightly limited feature set. > > Can you expand briefly how "limited" the feature set is? Does it only > disable some arcane features, so that e.g. asyncio + TLS supports works > fine? > > Other than that, it all sounds good to me. I honestly don't know because I lack the expertise and knowledge. LibreSSL has removed some features (env vars like SSL_CERT_FILE, ENGINE support) and added some other features. I cannot tell if stdlib ssl + LibreSSL is even secure. It probably is *if and only if* LibreSSL is 100% compatible to OpenSSL. Christian ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 2016-08-31 11:33, M.-A. Lemburg wrote: > On 31.08.2016 10:50, Christian Heimes wrote: >> On 2016-08-31 10:31, M.-A. Lemburg wrote: >>> 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). >> >> Are you willing to do implement and maintain this callback? Are you >> willing to do all work? > > Maintain: yes, if needed. > > It is already implemented, so that part isn't hard :-) No, it is not implemented as callback. It is implemented as post verification step, which is wrong. >> Are you aware how many security bugs we had in our own verification >> code? I'm aware of at least two critical bugs. > > Not that many, given that the host name validation is more > a best practices art rather than one where all participants > implement the standards: > > http://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid=file%3Acontent&%40search_text=match_hostname=search=-1%2C1%2C2%2C3 > > The only critical bug I could find was this one (NUL bytes > in subjectAltName): > > http://bugs.python.org/issue18709 > > but as I understand, the true origin of the bug was an OpenSSL > function, not the host name matching code in Python. Ah, I forgot about the NULL bytes issue. The bug is not caused by a problem in OpenSSL. We just the wrong function to convert General Name ASN.1 strings to unicode. Then there are four critical bugs: * NULL bytes in SAN * wrong, insecure RFC for wildcard matching * DoS caused excessive regular expression matching for wildcards * invalid handling of IDNA for wildcard matching IP address verification is still wrong, too. This was my last reply to your mails on this topic. It's clear to me that you are not open to Cory's, Nick's or my arguments and that you won't change your position. More replies are just a waste of my limited time. Instead I'm going to focus on a PEP to define OpenSSL support and to auto-deprecate unsupported OpenSSL versions. The PEP is a very high chance to get accepted. Everybody except you support the plan. Christian ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
Le 31/08/2016 à 11:33, M.-A. Lemburg a écrit : > On 31.08.2016 10:43, Antoine Pitrou wrote: >> On Wed, 31 Aug 2016 10:31:12 +0200 >> "M.-A. Lemburg"wrote: >>> >>> 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. >> >> There is a solution nowadays, which is to use Anaconda (or Miniconda). > > Sure, or use ActivePython or eGenix PyRun :-) Uh, right, I was being employer-biased here, sorry. > But is that really what we want to tell people ? Why not? python.org does not provide official binaries for Linux or Unix systems (except OS X), and most people don't like compile their infrastructure themselves. People who want an up-to-date Python can either use: - use the python.org binaries on OS X and Windows - use a recent OS providing a recent Python version (for Linux and Unix variants) - use a vendor-supported backport on old OSes (if so provided, for example on RedHat with Software Collections?) - use a third party-supported backport on old OSes (ActivePython, eGenix PyRun, etc.) - as a last resort, hand-compile their Python, in which case they have to be careful to gather the required dependencies Regards Antoine. ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 31.08.2016 10:43, Antoine Pitrou wrote: > On Wed, 31 Aug 2016 10:31:12 +0200 > "M.-A. Lemburg"wrote: >> >> 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. > > There is a solution nowadays, which is to use Anaconda (or Miniconda). Sure, or use ActivePython or eGenix PyRun :-) But is that really what we want to tell people ? -- 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/ ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 31.08.2016 10:50, Christian Heimes wrote: > On 2016-08-31 10:31, M.-A. Lemburg wrote: >> 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). > > Are you willing to do implement and maintain this callback? Are you > willing to do all work? Maintain: yes, if needed. It is already implemented, so that part isn't hard :-) > Are you aware how many security bugs we had in our own verification > code? I'm aware of at least two critical bugs. Not that many, given that the host name validation is more a best practices art rather than one where all participants implement the standards: http://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid=file%3Acontent&%40search_text=match_hostname=search=-1%2C1%2C2%2C3 The only critical bug I could find was this one (NUL bytes in subjectAltName): http://bugs.python.org/issue18709 but as I understand, the true origin of the bug was an OpenSSL function, not the host name matching code in Python. -- 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/ ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 2016-08-31 10:31, M.-A. Lemburg wrote: > 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). Are you willing to do implement and maintain this callback? Are you willing to do all work? Are you aware how many security bugs we had in our own verification code? I'm aware of at least two critical bugs. Christian ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Wed, 31 Aug 2016 10:31:12 +0200 "M.-A. Lemburg"wrote: > > 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. There is a solution nowadays, which is to use Anaconda (or Miniconda). Regards Antoine. ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 2016-08-30 22:07, M.-A. Lemburg wrote: > 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. That's wrong. ssl support is optional. hashlib builds without OpenSSL, too. > 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. OpenSSL 1.0.2 requirement is already postponed to 3.7. > 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. No, the SSL module will require features that are OpenSSL 1.0.2 only. >>> 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 ? Please read my mails. I gave you two reasons. First it's going to make my work harder and I'm not willing to invest extra work to supported deprecated, unsupported and insecure versions. Second I'm going to require features that are 1.0.2 only. Christian ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 31.08.2016 01:55, Gregory P. Smith wrote: > On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburgwrote: >>> 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
Re: [Python-Dev] Supported versions of OpenSSL
On 31 August 2016 at 00:55, Gregory P. Smithwrote: > 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 In our environment (corporate systems locked to older OS releases, with Python *not* a strategic solution but used for ad-hoc automation) it's quite common to find only an ancient version of Python available, but want to build a new version without any ability to influence corporate IT to allow new versions of the necessary libraries. But I strongly agree, this is *my* problem, and Python policy should not be based on the idea that what I want to do "should" be supported. So +1 on the proposed change here. Paul ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 31 August 2016 at 09:55, Gregory P. Smithwrote: > On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg wrote: >> 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. There's a 3rd variant, which is to raise support tickets with their LTS vendors to request compatibility backports. I strongly encourage that behaviour by end user organisations when wearing both my upstream volunteer contributor hat, since it means they're not bothering community volunteers with their institutional support requests, and my downstream redistributor employee hat, since the more Python related customer support requests Red Hat receives, the easier it gets for folks internally (including me) to put together business cases arguing for increased direct investment in the upstream Python ecosystem :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburgwrote: > 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 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
Re: [Python-Dev] Supported versions of OpenSSL
> On 30 Aug 2016, at 16:07, M.-A. Lemburgwrote: > > 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. > > 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. If your application doesn’t need SSL, then you can compile without OpenSSL. I just downloaded and compiled the current tip of the CPython repository on a system with no OpenSSL, and the world didn’t explode, it just printed this: Python build finished successfully! The necessary bits to build these optional modules were not found: _bz2 _curses _curses_panel _dbm _gdbm _lzma _sqlite3 _ssl _tkinter readline zlib To find the necessary bits, look in setup.py in detect_modules() for the module's name. So this user you have considered, who needs Python but not the ssl module, is still well served. The ssl module is not mandatory in CPython, and no-one is proposing that it should be. But the real question is this: who *is* this hypothetical user? This user apparently needs the latest CPython, but is entirely unwilling to update literally anything else, including moving to a more recent release of their operating system. They are equipped to compile Python from source, but are apparently unwilling or unable to install a more recent OpenSSL from source. I’m not entirely certain that python-dev should be supporting that user: that user should be contacting their LTS supplier. Cory ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
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. Lemburgwrote: 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
Re: [Python-Dev] Supported versions of OpenSSL
On Sun, 28 Aug 2016 22:40:11 +0200 Christian Heimeswrote: > > Here is the deal for 2.7 to 3.5: > > 1) All versions older than 0.9.8 are completely out-of-scope and no > longer supported. > > 2) 0.9.8 is semi-support. Python will still compile and work with 0.9.8. > However we do NOT promise that is secure to run 0.9.8. We also require a > recent version. Patch level 0.9.8zc from October 2014 is reasonable > because it comes with SCSV fallback (CVE-2014-3566). > > 3) 1.0.0 is irrelevant. Users are either stuck on 0.9.8 or are able to > upgrade to 1.0.1+. Let's not support it. > > 4) 1.0.1 is discouraged but still supported until its EOL. > > 5) 1.0.2 is the recommend version. > > 6) 1.1 support will be added by #26470 soon. > > 7) LibreSSL 2.3 is supported but with a slightly limited feature set. Can you expand briefly how "limited" the feature set is? Does it only disable some arcane features, so that e.g. asyncio + TLS supports works fine? Other than that, it all sounds good to me. Regards Antoine. ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 8/29/2016 10:59 PM, Nick Coghlan wrote: By contrast (and assuming I understand the situation correctly), the Windows build is already set up around the assumption that you'll need to build OpenSSL yourself. If one installs a minimal svn client and passes -e to Zack's wonderful built.bat, current versions of external dependencies are automatically downloaded and compiled with the result placed where needed. So I did nothing more to have OpenSSL updated to 1.0.2h last June. This is too easy to say I 'built it myself'. -- Terry Jan Reedy ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 30 August 2016 at 15:13, Benjamin Petersonwrote: > On Sun, Aug 28, 2016, at 22:42, Christian Heimes wrote: >> In my proto-PEP I'm talking about different levels of support: full, >> build-only and unsupported. Full support means that the combination of >> Python and OpenSSL versions is reasonable secure and recommended. >> >> On the other hand build-only support doesn't come with any security >> promise. The ssl and hashlib module are source compatible with OpenSSL >> 0.9.8. You can still compile Python, do https connections but they might >> not be secure. It's "Warranty void" mode. > > I'm not sure having such "support" is a good idea. If we're not able to > support a security module securely, it's probably better if it doesn't > compile at all. We may not be able to practically support these variations directly upstream, but that doesn't mean the particular downstream redistributor or end user building against the older version can't - they get to narrow their support matrix in a different way from us by only caring about their particular platform or deployment environment. So I don't think it makes sense to fight this particular battle right now - it may be something we want to explore in the future as a deliberate "You must have the ability to maintain patches against CPython and hence presumably OpenSSL if you want to use older OpenSSL versions" barrier to entry, but just the notion of imposing minimum OpenSSL versions on *nix and hence potentially deprecating upstream support for older LTS Linux releases before their distributors do is already going to be a significant change. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Sun, Aug 28, 2016, at 22:42, Christian Heimes wrote: > On 2016-08-29 04:38, Ned Deily wrote: > > On Aug 28, 2016, at 19:06, Benjamin Petersonwrote: > >> On Sun, Aug 28, 2016, at 13:40, Christian Heimes wrote: > >>> Here is the deal for 2.7 to 3.5: > >>> > >>> 1) All versions older than 0.9.8 are completely out-of-scope and no > >>> longer supported. > >> +1 > >>> 2) 0.9.8 is semi-support. Python will still compile and work with 0.9.8. > >>> However we do NOT promise that is secure to run 0.9.8. We also require a > >>> recent version. Patch level 0.9.8zc from October 2014 is reasonable > >>> because it comes with SCSV fallback (CVE-2014-3566). > >> I think we should support 0.9.8 for 2.7 and drop it for 3.6. > > > > Sounds good to me, too. I think we should also not change things for 3.5.x > > at this point, e.g. continue to support 0.9.8 there. > > > In my proto-PEP I'm talking about different levels of support: full, > build-only and unsupported. Full support means that the combination of > Python and OpenSSL versions is reasonable secure and recommended. > > On the other hand build-only support doesn't come with any security > promise. The ssl and hashlib module are source compatible with OpenSSL > 0.9.8. You can still compile Python, do https connections but they might > not be secure. It's "Warranty void" mode. I'm not sure having such "support" is a good idea. If we're not able to support a security module securely, it's probably better if it doesn't compile at all. ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Aug 29, 2016, at 22:59, Nick Coghlanwrote: > The other thing I've been looking at is how well documented the > process is for building with a custom OpenSSL instead of the system > one, and as near as I can tell, it isn't documented at all - the top > level README doesn't mention it, and because the compilation is > handled by setup.py rather than directly by make, there's no configure > option for it the way there is for "--with-system-expat", > "--with-system-libmpdec" and "--with-system-ffi". There is at least one open issue with a supplied patch to provide a --with-ssl configure option: http://bugs.python.org/issue21541 The patch may need some freshening up. There are also other open issues on configuring third-party libraries in general. > By contrast (and assuming I understand the situation correctly), the > Windows build is already set up around the assumption that you'll need > to build OpenSSL yourself. > > So, in addition to updating PEP 11 with guidelines for determining the > OpenSSL constraints for each release, I think we'll also need a README > update to cover building against a non-system OpenSSL. For OS X, we can copy the info about building with OpenSSL from Homebrew or MacPorts from the Developer's Guide. There are other things that could be done. The OS X installer build knows how to build OpenSSL as well as other needed libs. I'd like to refactor that to make those libs usable for non-installer builds. I've also thought it would be nice to provide simpler configure options to use Homebrew, MaPorts, or build-your-own. That's probably not going to happen in time for 3.6b1, though. -- Ned Deily n...@python.org -- [] ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 30 August 2016 at 08:56, Barry Warsawwrote: > On Aug 29, 2016, at 12:33 PM, Cory Benfield wrote: > >>Can someone explain to me why this is a use-case we care about? > > I do think it would be nice to be able to compile newer versions of Python on > stock LTS releases, especially for people developing software that they want > to support on a wide-range of Python 3 versions. Based on this discussion, I've been thinking about how we could articulate these build support constraints in PEP 11, similar to the https://www.python.org/dev/peps/pep-0011/#microsoft-windows section we have for Windows. For that, I think it makes sense to key off source compatibility with the most recent releases of long term community or commercially supported Linux distros that have folks directly involved in CPython development (specifically Debian stable, Ubuntu LTS, and RHEL/CentOS). The other thing I've been looking at is how well documented the process is for building with a custom OpenSSL instead of the system one, and as near as I can tell, it isn't documented at all - the top level README doesn't mention it, and because the compilation is handled by setup.py rather than directly by make, there's no configure option for it the way there is for "--with-system-expat", "--with-system-libmpdec" and "--with-system-ffi". By contrast (and assuming I understand the situation correctly), the Windows build is already set up around the assumption that you'll need to build OpenSSL yourself. So, in addition to updating PEP 11 with guidelines for determining the OpenSSL constraints for each release, I think we'll also need a README update to cover building against a non-system OpenSSL. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
> On 29 Aug 2016, at 15:31, M.-A. Lemburgwrote: > > 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. That's quite the non-sequitur. You never answered my question: what does "widely deployed" mean? At what level of deployment do we need to support the system configuration with no changes? Do we need to support compiling out of box with Windows 10? Because we don't: if they want SSL, we need them to compile and install an OpenSSL. Do we need to support compiling out of the box on macOS 10.12 Sierra? Because we don't: if they want SSL they need to install their own OpenSSL. At a certain point we need to give up on systems that do not provide up to date copies of important libraries, or say that if you want to use Python on them you need to compile without our support libraries. > 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. Yes, that's true. But on the other hand, that LTS release is *already out* at this time, and has been for four months. By the time of the release of Python 3.7 it will have been released for two years and two months. The request to upgrade is not unreasonable. > 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. Then Ubuntu can ship us an engineer who is willing to support the SSL module with OpenSSL 1.0.1 going forward. The one engineer we have has said he is unwilling to do it. > This doesn't sound like a feature worth breaking compatibility > to me. Does the compatibility guarantee apply to libraries that Python will link against? Cory ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 30 August 2016 at 02:33, Cory Benfieldwrote: > >> On 29 Aug 2016, at 04:09, M.-A. Lemburg 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? I can think of a few key cases where it's potentially going to have an impact: - availability of new Python versions in public PaaS environments - availability of new Python versions in free-for-open-source public CI services - the "maximum supported Python version" for iterations of the manylinux project Fortunately, public PaaS providers and public CI providers tend to fall into the "upgrade Linux when new LTS releases are available, not when the old ones are about to lose support" category, so a policy of targeting the latest LTS releases (perhaps with a "more than 12 months old" caveat) rather than the oldest still commercially supported ones should be sufficient on that front (if the LTS vendors decide they'd like us to change that policy, they always have the option of funding it accordingly). Currently, that means: - Debian 8 - Ubuntu 16.04 (or 14.04 with the "12 months old" caveat) - RHEL/CentOS 7 And then trusting that supporting those will also cover other Linux distros that aren't as directly involved in upstream CPython development. That means the main potential source of problems I see here is the manylinux project, but fortunately that concern was accounted for by explicitly excluding OpenSSL from the defined portable ABI: https://www.python.org/dev/peps/pep-0513/#security-implications So it's already a manylinux requirement that anyone wanting to use ssl in a portable way needs to either use the standard library module, or else something like PyOpenSSL (which bundles its own copy, independent of what the system provides) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 8/29/2016 5:20 PM, Christian Heimes wrote: On 2016-08-29 23:00, Gregory P. Smith wrote: Lets make 3.7 require a higher version. The common OSS OS distros of its time will be better prepared. Especially is warned. My multissl test script allows me to compile and test _ssl.c and _hashopenssl.c with multiple versions of OpenSSL and LibreSSL in less than a minute. For 3.6 I have verified source compatibility with 0.9.8zc (maybe even older) up to 1.1.0. My argument with MAL is about future features for 3.7. I'm not planning to require 1.0.2 APIs for 3.6 yet. This may change in case new security issues are found. I might clean up the ssl module and require 0.9.8zc+ during beta, though. So, in 3.6, and maybe even 3.5.3, add a deprecation warning when OSSL < 1.0.2 is used. -- Terry Jan Reedy ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Aug 29, 2016, at 12:33 PM, Cory Benfield wrote: >Can someone explain to me why this is a use-case we care about? I do think it would be nice to be able to compile newer versions of Python on stock LTS releases, especially for people developing software that they want to support on a wide-range of Python 3 versions. Sure, you can use your container of choice, and there are ways around this, but every hurdle just makes it more of a pain to do. So I'd say if we can keep the compatibility without too much effort, and without sacrificing the security or maintainability of the code, we should do it. If we can't, we can't. Cheers, -Barry ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 2016-08-29 23:00, Gregory P. Smith wrote: > > Given that you already said: > > """ > For 3.6 I don't require any 1.0.2 feature yet. The 1.1.0 patch keeps > code compatible with 0.9.8zc to 1.1.0. But as soon as I use new > features, the ssl module will no longer be source and build compatible > with < 1.0.2. There is also the point of OpenSSL 1.0.1. It reaches > end-of-lifetime by the end if this year. 1.0.2 will be supported until 2019. > > I'm tempted to require 1.0.2 for Python 3.6 but it's technically not > necessary yet. > """ > > That to me means we should keep support for 1.0.1 in Python 3.6 unless > there are features in 1.0.2 that you find are an absolute must have > within the next two weeks. We're going to be entering 3.6beta on > September 12th and current stable distros do not ship with a more recent > version so lets not make the lives of our developers and buildbot > maintainers hell by forcing them to install a special version. > > Lets make 3.7 require a higher version. The common OSS OS distros of its > time will be better prepared. My multissl test script allows me to compile and test _ssl.c and _hashopenssl.c with multiple versions of OpenSSL and LibreSSL in less than a minute. For 3.6 I have verified source compatibility with 0.9.8zc (maybe even older) up to 1.1.0. My argument with MAL is about future features for 3.7. I'm not planning to require 1.0.2 APIs for 3.6 yet. This may change in case new security issues are found. I might clean up the ssl module and require 0.9.8zc+ during beta, though. Christian ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Mon, Aug 29, 2016 at 1:18 PM Christian Heimeswrote: > 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 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. > > > > > 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 keep your dialog civil Christian. That was unwarranted. Nobody was forcing a burden upon you. 3.6 will remain buildable and usable on common stable distros so long as we support 1.0.1 which sounds easy to do. For 3.7 we can move on and raise the minimum beyond that. ... > opinion it is more than reasonable to ditch 1.0.1 and earlier. > Given that you already said: """ For 3.6 I don't require any 1.0.2 feature yet. The 1.1.0 patch keeps code compatible with 0.9.8zc to 1.1.0. But as soon as I use new features, the ssl module will no longer be source and build compatible with < 1.0.2. There is also the point of OpenSSL 1.0.1. It reaches end-of-lifetime by the end if this year. 1.0.2 will be supported until 2019. I'm tempted to require 1.0.2 for Python 3.6 but it's technically not necessary yet. """ That to me means we should keep support for 1.0.1 in Python 3.6 unless there are features in 1.0.2 that you find are an absolute must have within the next two weeks. We're going to be entering 3.6beta on September 12th and current stable distros do not ship with a more recent version so lets not make the lives of our developers and buildbot maintainers hell by forcing them to install a special version. Lets make 3.7 require a higher version. The common OSS OS distros of its time will be better prepared. -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
Re: [Python-Dev] Supported versions of OpenSSL
On 2016-08-29 22:10, Random832 wrote: > On Mon, Aug 29, 2016, at 04:09, M.-A. Lemburg wrote: >> 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. > > If someone's going to compile a new version of Python for Ubuntu LTS, > they can compile a new version of OpenSSL. How likely is it that someone > will want to use the packaged version of OpenSSL, but not use the > packaged version (which is 3.4) of Python? Please let me rephrase the question. How likely is it that somebody won't use a container to deploy more recent versions? It's 2016. Christian ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
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. Lemburgwrote: >>> >>> 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. > > 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 ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Mon, Aug 29, 2016, at 04:09, M.-A. Lemburg wrote: > 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. If someone's going to compile a new version of Python for Ubuntu LTS, they can compile a new version of OpenSSL. How likely is it that someone will want to use the packaged version of OpenSSL, but not use the packaged version (which is 3.4) of Python? ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 29.08.2016 18:33, Cory Benfield wrote: > >> On 29 Aug 2016, at 04:09, M.-A. Lemburgwrote: >> >> 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. 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. OTOH, the situations isn't all that bad: people on such systems will likely not go straight for the 3.7.0 release of Python, but instead wait for 3.7.2+ for the dust to settle. > The nature of a stable distribution is that all the packages are guaranteed > to work together. Once you start compiling your own software, you are out in > the cold: you are no longer covered by that guarantee. Why, then, should > someone compiling a version of Python that was barely conceived when Ubuntu > 14.04 was released expect that they can compile it from source using only > dependencies available in their mainline distribution? > > I absolutely understand wanting to support Ubuntu 14.04 for any release of > Python that already compiles on Ubuntu 14.04: that makes sense. But new > releases should not be shackled to what is in LTS releases of operating > systems. If it were, a more coherent argument would be that we cannot drop > 0.9.8 support in any Python released before the middle of 2017 because RHEL 5 > ships it, and we will not be able to require OpenSSL 1.0.2 until almost 2021 > because RHEL 6 ships 1.0.1. After all, why does Ubuntu 14.04 get privileged > over RHEL? Both are supported LTS releases, after all. > > I don’t believe that the Python dev team has ever promised that future > versions of Python will compile on a given LTS release. Am I mistaken? > > While I’m here, I should note that Ubuntu 14.04 goes EOL in 2019, while > OpenSSL 1.0.1 loses support from upstream at the end of this year, which is > probably a good reason to stop supporting it in new Python versions. OpenSSL > 1.0.0 and 0.9.8 are already unsupported by upstream. 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. 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. 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 ? >> 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. This doesn't sound like a feature worth breaking compatibility to me. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Aug 29 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/
Re: [Python-Dev] Supported versions of OpenSSL
On Mon, 29 Aug 2016 at 09:34 Cory Benfieldwrote: > > > On 29 Aug 2016, at 04:09, M.-A. Lemburg 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? > > The nature of a stable distribution is that all the packages are > guaranteed to work together. Once you start compiling your own software, > you are out in the cold: you are no longer covered by that guarantee. Why, > then, should someone compiling a version of Python that was barely > conceived when Ubuntu 14.04 was released expect that they can compile it > from source using only dependencies available in their mainline > distribution? > I also agree with this view. If you're on an LTS then you should expect everything that comes with the LTS to work, not new software that you pulled forward unless your OS distributor supports it, e.g. RHEL collections. > > I absolutely understand wanting to support Ubuntu 14.04 for any release of > Python that already compiles on Ubuntu 14.04: that makes sense. But new > releases should not be shackled to what is in LTS releases of operating > systems. If it were, a more coherent argument would be that we cannot drop > 0.9.8 support in any Python released before the middle of 2017 because RHEL > 5 ships it, and we will not be able to require OpenSSL 1.0.2 until almost > 2021 because RHEL 6 ships 1.0.1. After all, why does Ubuntu 14.04 get > privileged over RHEL? Both are supported LTS releases, after all. > No one gets special privileges beyond someone funding a core dev to put into the effort to support a platform that won't shackle others. > > I don’t believe that the Python dev team has ever promised that future > versions of Python will compile on a given LTS release. Am I mistaken? > No, literally the only support promise we make along these lines is that we will support Windows versions that are still in extended support: https://www.python.org/dev/peps/pep-0011/#id10 , and that promise only works due to Windows not being a moving target in terms of backwards-compatibility. > > While I’m here, I should note that Ubuntu 14.04 goes EOL in 2019, while > OpenSSL 1.0.1 loses support from upstream at the end of this year, which is > probably a good reason to stop supporting it in new Python versions. > OpenSSL 1.0.0 and 0.9.8 are already unsupported by upstream. > I agree w/ Christian's proposal of matching what OpenSSL upstream supports when releasing new versions of CPython. I don't see how supporting outdated security code is good for anyone involved. ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
> On 29 Aug 2016, at 04:09, M.-A. Lemburgwrote: > > 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? The nature of a stable distribution is that all the packages are guaranteed to work together. Once you start compiling your own software, you are out in the cold: you are no longer covered by that guarantee. Why, then, should someone compiling a version of Python that was barely conceived when Ubuntu 14.04 was released expect that they can compile it from source using only dependencies available in their mainline distribution? I absolutely understand wanting to support Ubuntu 14.04 for any release of Python that already compiles on Ubuntu 14.04: that makes sense. But new releases should not be shackled to what is in LTS releases of operating systems. If it were, a more coherent argument would be that we cannot drop 0.9.8 support in any Python released before the middle of 2017 because RHEL 5 ships it, and we will not be able to require OpenSSL 1.0.2 until almost 2021 because RHEL 6 ships 1.0.1. After all, why does Ubuntu 14.04 get privileged over RHEL? Both are supported LTS releases, after all. I don’t believe that the Python dev team has ever promised that future versions of Python will compile on a given LTS release. Am I mistaken? While I’m here, I should note that Ubuntu 14.04 goes EOL in 2019, while OpenSSL 1.0.1 loses support from upstream at the end of this year, which is probably a good reason to stop supporting it in new Python versions. OpenSSL 1.0.0 and 0.9.8 are already unsupported by upstream. Cory ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Mon, Aug 29, 2016 at 9:16 PM, Nick Coghlanwrote: > On 29 August 2016 at 21:05, Chris Angelico wrote: >> On Mon, Aug 29, 2016 at 8:52 PM, Nick Coghlan wrote: >>> For upcoming 3.6 I would like to limit support to 1.0.2+ and require >>> 1.0.2 features for 3.7. >> >> What does "limit support" mean? Will it be possible to build CPython >> 3.6 against OpenSSL 1.0.1? > > Christian clarified this later in the thread: > > - full support is stating confidently that software running that way > is using network connections that are as secure as we know how to make > them > - build support is ensuring it builds, without vouching one way or the > other for the security of the resulting network connections > - no support is "it doesn't build, but even if it did, we wouldn't > vouch for the security of the resulting connections" Sorry, my bad for just skimming the thread. There are comments like this: > I'm tempted to require 1.0.2 for Python 3.6 but it's technically not > necessary yet. > > #if OPENSSL_VERSION_INFO < 0x01000200L > # error "OpenSSL 1.0.2+ required" > #endif that led me to think that 3.6 was planning to demand 1.0.2, but if the intention is build support for 1.0.1, that would work. Sorry for the noise! ChrisA ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 29 August 2016 at 21:05, Chris Angelicowrote: > On Mon, Aug 29, 2016 at 8:52 PM, Nick Coghlan wrote: >> For upcoming 3.6 I would like to limit support to 1.0.2+ and require >> 1.0.2 features for 3.7. > > What does "limit support" mean? Will it be possible to build CPython > 3.6 against OpenSSL 1.0.1? Christian clarified this later in the thread: - full support is stating confidently that software running that way is using network connections that are as secure as we know how to make them - build support is ensuring it builds, without vouching one way or the other for the security of the resulting network connections - no support is "it doesn't build, but even if it did, we wouldn't vouch for the security of the resulting connections" Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Mon, Aug 29, 2016 at 8:52 PM, Nick Coghlanwrote: > On 29 August 2016 at 19:14, Chris Angelico wrote: >> On Mon, Aug 29, 2016 at 6:24 PM, Christian Heimes >> wrote: >>> No, LTS support should not be our concern. If you need a brand new >>> version of Python on an old LTS or Enterprise version of your OS, please >>> contact your vendor and buy support. You don't get to run old metal and >>> play with shiny new toys at the same time for free. >> >> I think I agree with you, but I'm not fully convinced. The current >> stable Debian (Jessie) also ships OpenSSL 1.0.1, although 1.0.2 is >> available in backports. The next stable release (Stretch) is expected >> some time 2017. > > I agree keeping build compatibility with the latest Debian stable > release is a sensible baseline, but 3.7 won't land until some time in > 2018, so Christian's proposed timeline still works on that front (but > jumping straight to requiring 1.0.2 in 3.6 wouldn't, suggesting that > supporting the latest Debian stable release will be a genuinely useful > guideline in helping to make decisions about minimum supported OpenSSL > versions for new CPython releases). Cool. I may have slightly misunderstood this from the OP: > For upcoming 3.6 I would like to limit support to 1.0.2+ and require > 1.0.2 features for 3.7. What does "limit support" mean? Will it be possible to build CPython 3.6 against OpenSSL 1.0.1? For 3.7, sure. Once Stretch has been stable for a year, it's not unreasonable to declare that the newest Python won't run on oldstable. Just not so sure about 3.6, where Stretch won't be stable yet. But even there, Jessie has been stable since Apr 2015 (so, 18 months or so by the time Python 3.6 comes out - that's one entire Python release), so I could well understand not wanting to be shackled by it. Saying "the latest CPython demands that you enable backports in your apt sources.list" wouldn't be unreasonable. ChrisA ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 29 August 2016 at 19:14, Chris Angelicowrote: > On Mon, Aug 29, 2016 at 6:24 PM, Christian Heimes > wrote: >> No, LTS support should not be our concern. If you need a brand new >> version of Python on an old LTS or Enterprise version of your OS, please >> contact your vendor and buy support. You don't get to run old metal and >> play with shiny new toys at the same time for free. > > I think I agree with you, but I'm not fully convinced. The current > stable Debian (Jessie) also ships OpenSSL 1.0.1, although 1.0.2 is > available in backports. The next stable release (Stretch) is expected > some time 2017. I agree keeping build compatibility with the latest Debian stable release is a sensible baseline, but 3.7 won't land until some time in 2018, so Christian's proposed timeline still works on that front (but jumping straight to requiring 1.0.2 in 3.6 wouldn't, suggesting that supporting the latest Debian stable release will be a genuinely useful guideline in helping to make decisions about minimum supported OpenSSL versions for new CPython releases). Assuming the checks for required OpenSSL features are able to be implemented as feature guards rather than as a plain version check (e.g. by issuing a warning if the detected SSL version is too low, but otherwise letting the build continue), other distros will also be able to keep new CPython versions building just by backporting the required OpenSSL features. More generally, it's important for folks to keep in mind that where most commercial Linux redistributors invest directly in upstream maintenance by assigning people to work on the kernel and other low level infrastructure pieces full time (including the community distros where those components are most actively developed), Python's commercial redistributors aren't as well behaved, so we currently have just the one full time developer working on PyPI and related PyPA tooling, and a few folks that have successfully negotiated part-time upstream CPython involvement as a condition of their employment. That disparity means we have to start getting much better at offloading security-sensitive work from CPython's volunteers to paid Linux developers in cases where it's feasible for us to do so, even if that in turn means requiring that Linux distros (both community and commercial) pay much closer attention to keeping their network security libraries up to date if they want their users to be readily able to build and run the latest Python feature releases. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Mon, Aug 29, 2016 at 6:24 PM, Christian Heimeswrote: > No, LTS support should not be our concern. If you need a brand new > version of Python on an old LTS or Enterprise version of your OS, please > contact your vendor and buy support. You don't get to run old metal and > play with shiny new toys at the same time for free. I think I agree with you, but I'm not fully convinced. The current stable Debian (Jessie) also ships OpenSSL 1.0.1, although 1.0.2 is available in backports. The next stable release (Stretch) is expected some time 2017. That's not the same as "running an old LTS" - that's running the latest non-dev release. Is it acceptable to tell people to install a library from backports if they want to compile the latest Python? ChrisA ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Mon, Aug 29, 2016 at 10:24:42AM +0200, Christian Heimes wrote: > On 2016-08-29 10:09, M.-A. Lemburg 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. > > No, LTS support should not be our concern. If you need a brand new > version of Python on an old LTS or Enterprise version of your OS, please > contact your vendor and buy support. You don't get to run old metal and > play with shiny new toys at the same time for free. Well, it's an additional annoyance for sure: $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 14.04.4 LTS Release:14.04 Codename: trusty I'm not in the habit of updating my OS constantly. [Before this attracts some of the usual lectures, I know how to install OpenSSL, thanks.] Stefan Krah ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 2016-08-29 10:09, M.-A. Lemburg 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. No, LTS support should not be our concern. If you need a brand new version of Python on an old LTS or Enterprise version of your OS, please contact your vendor and buy support. You don't get to run old metal and play with shiny new toys at the same time for free. By the way I knew that something like this would come up from you. Thank you that you satisfied my expectation. :p > 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. Christian ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
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. 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 ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Aug 29 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/ ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 2016-08-29 04:38, Ned Deily wrote: > On Aug 28, 2016, at 19:06, Benjamin Petersonwrote: >> On Sun, Aug 28, 2016, at 13:40, Christian Heimes wrote: >>> Here is the deal for 2.7 to 3.5: >>> >>> 1) All versions older than 0.9.8 are completely out-of-scope and no >>> longer supported. >> +1 >>> 2) 0.9.8 is semi-support. Python will still compile and work with 0.9.8. >>> However we do NOT promise that is secure to run 0.9.8. We also require a >>> recent version. Patch level 0.9.8zc from October 2014 is reasonable >>> because it comes with SCSV fallback (CVE-2014-3566). >> I think we should support 0.9.8 for 2.7 and drop it for 3.6. > > Sounds good to me, too. I think we should also not change things for 3.5.x > at this point, e.g. continue to support 0.9.8 there. In my proto-PEP I'm talking about different levels of support: full, build-only and unsupported. Full support means that the combination of Python and OpenSSL versions is reasonable secure and recommended. On the other hand build-only support doesn't come with any security promise. The ssl and hashlib module are source compatible with OpenSSL 0.9.8. You can still compile Python, do https connections but they might not be secure. It's "Warranty void" mode. >>> 3) 1.0.0 is irrelevant. Users are either stuck on 0.9.8 or are able to >>> upgrade to 1.0.1+. Let's not support it. >>> >>> 4) 1.0.1 is discouraged but still supported until its EOL. >>> >>> 5) 1.0.2 is the recommend version. >>> >>> 6) 1.1 support will be added by #26470 soon. > > [...] > >>> For upcoming 3.6 I would like to limit support to 1.0.2+ and require >>> 1.0.2 features for 3.7. > > It's not clear to me what you are proposing as the differences between 3.6 > ("limit support to 1.0.2+") and 3.7 ("require 1.0.2 features"). Could you > elaborate? For 3.6 I don't require any 1.0.2 feature yet. The 1.1.0 patch keeps code compatible with 0.9.8zc to 1.1.0. But as soon as I use new features, the ssl module will no longer be source and build compatible with < 1.0.2. There is also the point of OpenSSL 1.0.1. It reaches end-of-lifetime by the end if this year. 1.0.2 will be supported until 2019. I'm tempted to require 1.0.2 for Python 3.6 but it's technically not necessary yet. #if OPENSSL_VERSION_INFO < 0x01000200L # error "OpenSSL 1.0.2+ required" #endif > >>> What is the status of Python.org's OSX builds? >>> Is it possible to drop 0.9.8? > > I think we can safely drop 0.9.8 support in 3.6. If anyone is aware of any > supported platform where this will would cause a problem, please speak up now. > > With regard to OS X (or macOS, as the upcoming next major release is called), > the 3.6.0 python.org OS X installer will supply a private copy of OpenSSL > 1.0.2+. Most other third-party distributors of Python on OS X already do not > use the Apple-suplied deprecated system OpenSSL libs. As of the current OS X > 10.11 El Capitan, Apple no longer supplies the header files for OpenSSL in > either Xcode macosx SDK or in the optional Command Line Tools /usr/include > headers so, if you want to build Python on OS X, you now need to use a > non-system copy of OpenSSL anyway (the devguide explains how to build with > OpenSSL libs from either Homebrew or MacPorts). The shared libs are still > supplied for the benefit of applications built on older releases and for the > Apple-supplied system Pythons (2.6.x and 2.7 > .x, still no 3.x). I'm glad to hear that. Thanks :) Christian ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Aug 28, 2016, at 19:06, Benjamin Petersonwrote: > On Sun, Aug 28, 2016, at 13:40, Christian Heimes wrote: >> Here is the deal for 2.7 to 3.5: >> >> 1) All versions older than 0.9.8 are completely out-of-scope and no >> longer supported. > +1 >> 2) 0.9.8 is semi-support. Python will still compile and work with 0.9.8. >> However we do NOT promise that is secure to run 0.9.8. We also require a >> recent version. Patch level 0.9.8zc from October 2014 is reasonable >> because it comes with SCSV fallback (CVE-2014-3566). > I think we should support 0.9.8 for 2.7 and drop it for 3.6. Sounds good to me, too. I think we should also not change things for 3.5.x at this point, e.g. continue to support 0.9.8 there. >> 3) 1.0.0 is irrelevant. Users are either stuck on 0.9.8 or are able to >> upgrade to 1.0.1+. Let's not support it. >> >> 4) 1.0.1 is discouraged but still supported until its EOL. >> >> 5) 1.0.2 is the recommend version. >> >> 6) 1.1 support will be added by #26470 soon. [...] >> For upcoming 3.6 I would like to limit support to 1.0.2+ and require >> 1.0.2 features for 3.7. It's not clear to me what you are proposing as the differences between 3.6 ("limit support to 1.0.2+") and 3.7 ("require 1.0.2 features"). Could you elaborate? >> What is the status of Python.org's OSX builds? >> Is it possible to drop 0.9.8? I think we can safely drop 0.9.8 support in 3.6. If anyone is aware of any supported platform where this will would cause a problem, please speak up now. With regard to OS X (or macOS, as the upcoming next major release is called), the 3.6.0 python.org OS X installer will supply a private copy of OpenSSL 1.0.2+. Most other third-party distributors of Python on OS X already do not use the Apple-suplied deprecated system OpenSSL libs. As of the current OS X 10.11 El Capitan, Apple no longer supplies the header files for OpenSSL in either Xcode macosx SDK or in the optional Command Line Tools /usr/include headers so, if you want to build Python on OS X, you now need to use a non-system copy of OpenSSL anyway (the devguide explains how to build with OpenSSL libs from either Homebrew or MacPorts). The shared libs are still supplied for the benefit of applications built on older releases and for the Apple-supplied system Pythons (2.6.x and 2.7.x, still no 3.x). > Thanks for writing this patch! Ditto! -- Ned Deily n...@python.org -- [] ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On 29 August 2016 at 06:40, Christian Heimeswrote: > Hi, > > we need to talk about OpenSSL and LibreSSL before the next release of > Python. I'm working on a PEP. Most likely it won't be ready before the > feature freeze. If it's just drafting work that you need help with on that front, feel free to send me what you have and I can work it up into PEP form so folks can see a consolidated list of the proposed changes. > 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). Back when I wrote PEP 466, Ned indicated he was in favour of switching to static linking for the Mac OS X installers: https://mail.python.org/pipermail/python-dev/2014-March/133347.html So for 3.6, I agree with Benjamin's suggestion that we drop 0.9.8 support as well. For 2.7, I think we should defer the decision on what to do to a follow-up to PEP 466 that resyncs 2.7 with the Python 3.6 network security stack (while 466 got 2.7 to parity with 3.4.3, even that's starting to show its age now) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
> On 28 Aug 2016, at 16:40, Christian Heimeswrote: > > For upcoming 3.6 I would like to limit support to 1.0.2+ and require > 1.0.2 features for 3.7. What is the status of Python.org's OSX builds? > Is it possible to drop 0.9.8? I strongly support this change. Python with old OpenSSL versions is an enormous source of difficult-to-debug problems for users attempting to work with the web, and puts our users at totally unnecessary risk. Let’s move on. Cory ___ 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
Re: [Python-Dev] Supported versions of OpenSSL
On Sun, Aug 28, 2016, at 13:40, Christian Heimes wrote: > Here is the deal for 2.7 to 3.5: > > 1) All versions older than 0.9.8 are completely out-of-scope and no > longer supported. +1 > > 2) 0.9.8 is semi-support. Python will still compile and work with 0.9.8. > However we do NOT promise that is secure to run 0.9.8. We also require a > recent version. Patch level 0.9.8zc from October 2014 is reasonable > because it comes with SCSV fallback (CVE-2014-3566). I think we should support 0.9.8 for 2.7 and drop it for 3.6. > > 3) 1.0.0 is irrelevant. Users are either stuck on 0.9.8 or are able to > upgrade to 1.0.1+. Let's not support it. > > 4) 1.0.1 is discouraged but still supported until its EOL. > > 5) 1.0.2 is the recommend version. > > 6) 1.1 support will be added by #26470 soon. Thanks for writing this patch! ___ 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
[Python-Dev] Supported versions of OpenSSL
Hi, we need to talk about OpenSSL and LibreSSL before the next release of Python. I'm working on a PEP. Most likely it won't be ready before the feature freeze. But first let me start with some good news. OpenSSL 1.1 was released a couple of days ago. It changed a lot of aspects of its internal API, e.g. all structs are opaque and must be allocated / freed with OpenSSL API calls. Since I have been tracking changes in OpenSSL for the last half year and have submitted a couple of patches to OpenSSL, we are in a good shape. My patch https://bugs.python.org/issue26470 makes Python 2 and 3 compatible with OpenSSL 0.9.8 to 1.1.0 and with LibreSSL, too. It needs to go through review, though. I have asked Alex to verify my patch. Now to the bad news. The SSL module is a mess. It looks like a junk room owned by collector of ancient OpenSSL versions. For example it contains version checks for OpenSSL 0.9.5 -- which was decommissioned in 2000! That pre-dates new style classes! 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). Here is the deal for 2.7 to 3.5: 1) All versions older than 0.9.8 are completely out-of-scope and no longer supported. 2) 0.9.8 is semi-support. Python will still compile and work with 0.9.8. However we do NOT promise that is secure to run 0.9.8. We also require a recent version. Patch level 0.9.8zc from October 2014 is reasonable because it comes with SCSV fallback (CVE-2014-3566). 3) 1.0.0 is irrelevant. Users are either stuck on 0.9.8 or are able to upgrade to 1.0.1+. Let's not support it. 4) 1.0.1 is discouraged but still supported until its EOL. 5) 1.0.2 is the recommend version. 6) 1.1 support will be added by #26470 soon. 7) LibreSSL 2.3 is supported but with a slightly limited feature set. LibreSSL removed some features like SSL_CERT_FILE and OPENSSL_CONF env vars. For upcoming 3.6 I would like to limit support to 1.0.2+ and require 1.0.2 features for 3.7. What is the status of Python.org's OSX builds? Is it possible to drop 0.9.8? Christian ___ 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