[Python-Dev] PYTHONHTTPSVERIFY env var

M.-A. Lemburg mal at egenix.com
Mon May 11 12:58:19 CEST 2015

On 11.05.2015 12:47, Nick Coghlan 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 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

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

More information about the Python-Dev mailing list