[Python-Dev] PYTHONHTTPSVERIFY env var

[Nick Coghlan]

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