[Python-Dev] PYTHONHTTPSVERIFY env var (original) (raw)

Robert Kuska rkuska at redhat.com
Mon May 11 14:15:59 CEST 2015

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

More information about the Python-Dev mailing list