Re: [Python-Dev] Supported versions of OpenSSL

[Brett Cannon]

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 Coghlan  wrote:

> 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

[M.-A. Lemburg]

On 31.08.2016 14:02, Nick Coghlan wrote:
> 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.

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

[Nick Coghlan]

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/archive%40mail-archive.com

Re: [Python-Dev] Supported versions of OpenSSL

[Nick Coghlan]

On 31 August 2016 at 19:33, M.-A. Lemburg  wrote:
> 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

[M.-A. Lemburg]

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

[Christian Heimes]

On 2016-08-30 18:00, Antoine Pitrou wrote:
> On Sun, 28 Aug 2016 22:40:11 +0200
> 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.
>>
>> 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

[Christian Heimes]

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

[Antoine Pitrou]

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

[M.-A. Lemburg]

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

[M.-A. Lemburg]

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

[Christian Heimes]

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

[Antoine Pitrou]

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

[Christian Heimes]

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

[M.-A. Lemburg]

On 31.08.2016 01:55, Gregory P. Smith wrote:
> On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg  wrote:
>>> On 29.08.2016 22:16, Christian Heimes wrote:
>>> In my
>>> opinion it is more than reasonable to ditch 1.0.1 and earlier.
>>
>> I want you to consider the consequences of doing this carefully.
>>
> 
> We have. The proposal now stands at: We're free to ditch 1.0.1 and earlier
> support in 3.7 as soon as we have a need for a 1.0.2 specific API.
> 
> There don't seem to be any important negative consequences of doing so.

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

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

The only argument Christian reported was this one:

"""
> BTW: Are there any features in 1.0.2 that we need and would warrant
> dropping support for 1.0.1 earlier than Ubuntu 14.04 LTS ?

Yes, there are features I want to use, e.g. proper hostname
verification. Python's post-handshake verification is a hack and leads
to information disclosure.
"""

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

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

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

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

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

>> Crypto is important to have, but at the same time it's not
>> essentially for everything you do in Python, e.g. you can
>> easily run data analysis scripts or applications without ever
>> touching the ssl module.
> 
> While technically true, the ssl module is required to fetch and install
> software via pip which for casual users means it is essential. People can
> always operate without it if they are willing to download and build the
> libraries they need manually.
>
>> Yet, a move to require OpenSSL 1.0.2 for Python 3.7 will make
>> it impossible to run such apps on systems that still use OpenSSL
>> 1.0.1, e.g. Ubuntu 14.04 or CentOS 7.
>>
> 
> Not important. That isn't something we need to worry about. Compiling a new
> libssl is easy.  People using systems that are 4+ years old by the time 3.7
> comes out who expect new software to compile and just work are expecting
> too much.

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

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

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

>> Why not make the 1.0.2 and 1.1.0 support optional as we do
>> in so many other situations for various systems and libs ?
>>
> 
> In general, conditional compilation complicates code and adds a maintenance
> burden. The sooner we can ditch older versions, the cleaner and easier to
> maintain our code is.

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

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

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

I am thinking of Python users out there who are running on LTS
OS releases simply 

Re: [Python-Dev] Supported versions of OpenSSL

[Paul Moore]

On 31 August 2016 at 00:55, Gregory P. Smith  wrote:
> 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

[Nick Coghlan]

On 31 August 2016 at 09:55, Gregory P. Smith  wrote:
> 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

[Gregory P. Smith]

On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg  wrote:

> On 29.08.2016 22:16, Christian Heimes wrote:
> > On 2016-08-29 21:31, M.-A. Lemburg wrote:
> >> On 29.08.2016 18:33, Cory Benfield wrote:
> >>>
>  On 29 Aug 2016, at 04:09, M.-A. Lemburg  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

[Cory Benfield]

> On 30 Aug 2016, at 16: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.
> 
> 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

[M.-A. Lemburg]

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

[Antoine Pitrou]

On Sun, 28 Aug 2016 22:40:11 +0200
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.
> 
> 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

[Terry Reedy]

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

[Nick Coghlan]

On 30 August 2016 at 15:13, Benjamin Peterson  wrote:
> 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

[Benjamin Peterson]

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 Peterson  wrote:
> >> 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

[Ned Deily]

On Aug 29, 2016, at 22:59, Nick Coghlan  wrote:
> 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

[Nick Coghlan]

On 30 August 2016 at 08:56, Barry Warsaw  wrote:
> 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

[Cory Benfield]

> On 29 Aug 2016, at 15:31, M.-A. Lemburg  wrote:
> 
> 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

[Nick Coghlan]

On 30 August 2016 at 02: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?

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

[Terry Reedy]

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

[Barry Warsaw]

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

[Christian Heimes]

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

[Gregory P. Smith]

On Mon, Aug 29, 2016 at 1:18 PM 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.
>
> >
> > 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

[Christian Heimes]

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

[Christian Heimes]

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.

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

[Random832]

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

[M.-A. Lemburg]

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.

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

[Brett Cannon]

On Mon, 29 Aug 2016 at 09:34 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?
>
> 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

[Cory Benfield]

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

[Chris Angelico]

On Mon, Aug 29, 2016 at 9:16 PM, Nick Coghlan  wrote:
> 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

[Nick Coghlan]

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"

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

[Chris Angelico]

On Mon, Aug 29, 2016 at 8:52 PM, Nick Coghlan  wrote:
> 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

[Nick Coghlan]

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

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

[Chris Angelico]

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

[Stefan Krah]

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

[Christian Heimes]

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

[M.-A. Lemburg]

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

[Christian Heimes]

On 2016-08-29 04:38, Ned Deily wrote:
> On Aug 28, 2016, at 19:06, Benjamin Peterson  wrote:
>> 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

[Ned Deily]

On Aug 28, 2016, at 19:06, Benjamin Peterson  wrote:
> 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

[Nick Coghlan]

On 29 August 2016 at 06:40, Christian Heimes  wrote:
> 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

[Cory Benfield]

> On 28 Aug 2016, at 16:40, Christian Heimes  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 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

[Benjamin Peterson]

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