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

Nick Coghlan ncoghlan at gmail.com
Mon May 11 11:13:30 CEST 2015

On 11 May 2015 at 18:04, M.-A. Lemburg <mal at egenix.com> wrote:

On 10.05.2015 05:04, Robert Collins wrote:

On 10 May 2015 at 11:44, Chris Angelico <rosuav at gmail.com> wrote:

On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg <mal at egenix.com> wrote:

By providing a way to intentionally switch off the new default, we do make people aware of the risks and that's good enough, while still maintaining the contract people rightly expect of patch level releases of Python.

Just as long as it's the sysadmin, and NOT some random attacker over the internet, who has the power to downgrade security. Environment variables can be attacked in various ways. They can, and the bash fun was very good evidence of that. OTOH if someones environment is at risk, PATH and PYTHONPATH are already very effective attack vectors. If an attacker has access to the process environment, you're doomed anyway, so that's not really an argument for or against using environment variables :-)

The core issue lies in managing the "user" vs "administrator" permissions split. Even for self-administered systems, it's recommended practice to run without administrative permissions normally, and only elevate when you need them. One of the things you're watching out for in such cases is that it shouldn't be possible for an attacker to make a change to the user environment, and have that propagate to have an effect on a process running with administrative access. One of the recommended hardening measures against that kind of attack vector is to turn off Python's environment variable processing when launching Python processes with administrative access.

We didn't care about that in the hash randomisation case, as the compatibility concern there applied on a per application basis, and caring about hash order was technically a bug in its own right. By contrast, in the situation we're worried about for certificate verification compatibility, the issue is environmental: certificate management in many private intranets isn't yet to the same standard as that on the public internet, so administrators may have a valid reason for defaulting Python back to the old behaviour, and redistributors may feel obliged to provide an opt-in period prior to switching the default behaviour to opt-out. Having the new setting be ignored in Python processes run under a hardened configuration means that an environment variable based solution won't have the desired effect in providing that smoother migration path to the more hardened configuration.

I've now written a draft "recommendations to redistributors" PEP for Robert's configuration file based design: https://www.python.org/dev/peps/pep-0493/ (exact file names & config setting names TBD)

I wouldn't be opposed to seeing that as an upstream Python 2.7.x feature, but agreement amongst redistributors on using a file-based approach is the main outcome I'm looking for.

Regards, Nick.

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

More information about the Python-Dev mailing list