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

Donald Stufft donald at stufft.io
Tue May 12 13:45:43 CEST 2015

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

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).

Honestly, this reads like "If the person bundling 2.7.9 with their app doesn't bother to pay attention to what 2.7.9 means then things might break", but that's hardly special to TLS, there are lots of things that change in a release that may end up breaking in certain cases.

Looking at Marc-Andre's latest email though, it appears we're using bundling in a different context? I'm thinking of things like PyInstaller or such where you're distributing Python + your own App, but this appears to just be some third party tool is installing Python and an App?

Ultimately, as long as it doesn't end up in upstream CPython the PEP can recommend any approach and I'm OK with it in the sense that it won't affect me. Though the PEP should be clear it's for 2.7 only and not 3.x or 2.8 if that ever gets reversed and we end up with a 2.8.

Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://mail.python.org/pipermail/python-dev/attachments/20150512/bf7680ba/attachment.sig>

More information about the Python-Dev mailing list