On 11.05.2015 12:47, Nick Coghlan 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 guess we're approaching this from different perspectives :-) I'm mostly interested in having a switch that can be set on a per application basis, not globally. I think the global default is fine and I'm just looking for a way to have admins disable it on a case-by-case basis for those applications which have problems with the new default. Hence the env var approach - the admin would simply edit the application's startup shell script, add the env var and that's it. For pip et al. which don't use the ssl module, the admins can simply continue using older versions for those applications - ones which don't implement the extra verification. In many cases, this is not necessary, since production environments typically don't use PyPI at all: they use a local directory with the needed distribution files, which is both more secure and reliable. > 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" :) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 11 2015) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: 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/ _______________________________________________ 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
