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

Nick Coghlan ncoghlan at gmail.com
Tue May 12 13:40:01 CEST 2015

On 12 May 2015 at 21:21, Donald Stufft <donald at stufft.io> wrote:

On May 12, 2015, at 7:17 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 12 May 2015 at 21:09, Donald Stufft <donald at stufft.io> wrote: If you control the app you don't need to do that. All relevant api accept the context parameter. The shims are only useful when you don't control the app. So an app shipping their own python doesn't fall under that. I think the "bundled Python" scenario MAL is interested in is this one: 1. An application with a bundled CPython runtime is using the verification defaults 2. Upgraded the bundled Python to 2.7.9 3. Didn't provide new configuration settings to disable certificate verification 4. Is being upgraded in an environment where verifying certificates makes the app unusable for environmental reasons related to certificate management The PyRun single-file Python interpreter has a similar need, where some apps than ran fine under 2.7.8 will need a way to disable cert verification in 2.7.9+ on a per-application basis, without modifying the applications. Both of those make sense to me as cases where the environment variable based security downgrade approach is the "least bad" answer available, which is why I eventually agreed it should be one of the recommendations in the PEP. Why is without modifying the app a reasonable goal? If Python is bundled with the app then you have direct control over when that upgrade happens, so you can delay the upgrade to 2.7.9 until your application which is bundling Python has the relevant switches. This is distinctly different from a situation like downstream distributors where the version of Python being provided is being provided by a group different than the person providing the application.

Because of the way redistribution works. MAL was right that I was thinking specifically in terms of the Linux distributor case, where we're the OS vendor, so we need a way to offer "off by default, opt-in on a per-server basis". Once I got past that perspective, I was able to figure out where he was coming from as someone that offers explicit support for the "redistribution for bundling" use case.

When apps "bundle Python", what's usually happening is that they'll just bundle whatever version is used on the build server that does the bundling. If the app developer's testing all uses valid HTTPS certificates (or simply doesn't test HTTPS at all), they won't see any problems with the 2.7.9 upgrade, and hence will ship that along to their customers, where it may break if that customer's environment turns out to be relying on the lack of certificate verification in 2.7.8 and earlier.

If that scenario happens with unmodified upstream 2.7.9, the redistributor has no workaround they can pass along to app developers to in turn pass on to customers - the app developer simply has to tell their customers to downgrade back to the previous release, and then issue an updated version with a configuration setting to disable HTTPS verification as fast as they can. Customers tend to get rather grouchy about things like that :)

By contrast, if the redistributor for the bundled version of Python has injected PYTHONHTTPSVERIFY support, then the app developers can at least pass along "set PYTHONHTTPSVERIFY=0 in the environment" to their customers as an interim workaround until they get a release out the door with a proper configuration setting to control whether or not the app verifies certificates (assuming they don't decide the environment variable is a good enough workaround).

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list