[Python-Dev] PYTHONHTTPSVERIFY env var

[Robert Kuska]

----- Original Message -----
> From: "Donald Stufft" <donald at stufft.io>
> To: "Nick Coghlan" <ncoghlan at gmail.com>
> Cc: "python-dev" <python-dev at python.org>, "M.-A. Lemburg" <mal at egenix.com>
> Sent: Monday, May 11, 2015 1:16:58 PM
> Subject: Re: [Python-Dev] PYTHONHTTPSVERIFY env var
> 
> 
> > On May 11, 2015, at 6:47 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > 
> > On 11 May 2015 at 20:23, Donald Stufft <donald at stufft.io> wrote:
> >> On May 11, 2015, at 6:15 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >>> We made the decision when PEP 476 was accepted that this change turned
> >>> a silent security failure into a noisy one, rather than being a
> >>> regression in its own right. PEP 493 isn't about disagreeing with that
> >>> decision, it's about providing a smoother upgrade path in contexts
> >>> where letting the security failure remain silent is deemed to be
> >>> preferred in the near term.
> >> 
> >> I don't really agree that the decision to disable TLS is an environment
> >> one,
> >> it's really a per application decision. This is why I was against having
> >> some
> >> sort of global off switch for all of Python because just because one
> >> application needs it turned off doesn't mean you want it turned off for
> >> another
> >> Python application.
> > 
> > The scenario I'm interested in is the one where it *was* off globally
> > (i.e. you were already running Python 2.7.8 or earlier) and you want
> > to manage a global rollout of a new Python version that supports being
> > configured to verify HTTPS certificates by default, while making the
> > decision on whether or not to enable HTTPS certificate verification on
> > a server-by-server basis, rather than having that decision be coupled
> > directly to the rollout of the updated version of Python.
> > 
> > I agree that the desired end state is where Python 3 is, and where
> > upstream Python 2.7.9+ is, this is solely about how to facilitate
> > folks getting from point A to point B without an intervening window of
> > "I broke the world and now my boss is yelling at me about it" :)
> > 
> 
> Oh, another issue that I forgot to mention--
> 
> A fair number of people had no idea that Python wasn't validating TLS before
> 2.7.9/3.4.3 however as part of the processing of changing that in 2.7.9 a lot
> of people became aware that Python's before 2.7.9 didn't validate but that
> Python 2.7.9+ does. I worry that if Redhat (or anyone) ships a Python 2.7.9
> that doesn't verify by default then they are going to be shipping something
> which defies the expectations of those users who were relying on the fact
> that
> Python 2.7.9+ was supposed to be secure by default now. You're
> (understandibly)
> focusing on "I already have my thing running on Python 2.7.8 and I want to
> yum update and get 2.7.9 and have things not visibly break", however there is
> the other use case of "I'm setting up a new environment, and I installed RHEL
> and got 2.7.9, I remembered reading in LWN that 2.7.9 verifies now so I must
> be safe". If you *do* provide such a switch, defaulting it to verify and
> having

We (Red Hat) will not update python to 2.7.9, we ship 2.7.5 and backport 
bugfixes/features based on users demand.

> people where that breaks go in and turn it off is probably a safer mechanism
> since the cases where 2.7.9 verification breaks things for people is a
> visible
> change where the case that someone expects 2.7.9 to verify and it doesn't
> isn't
> a visible change and is easily missed unless they go out of their way to try
> and test it against a server with an invalid certificate.
> 
> Either way, if there is some sort of global off switch, having that off
> switch
> set to off should raise some kind of warning (like urllib3 does if you use
> the unverified HTTPS methods). To be clear, I don't mean that using the built
> in ssl module APIs to disable verification should raise a warning, I mean the
> hypothetical "make my Python insecurely access HTTPS" configuration file (or
> environment variable) that is being proposed.
> 
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rkuska%40redhat.com
> 


Regards
Robert Kuska
{rkuska}