----- Original Message ----- > From: "Donald Stufft" <don...@stufft.io> > To: "Nick Coghlan" <ncogh...@gmail.com> > Cc: "python-dev" <python-dev@python.org>, "M.-A. Lemburg" <m...@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 <ncogh...@gmail.com> wrote: > > > > On 11 May 2015 at 20:23, Donald Stufft <don...@stufft.io> wrote: > >> On May 11, 2015, at 6:15 AM, Nick Coghlan <ncogh...@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@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} _______________________________________________ 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
