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

M.-A. Lemburg mal at egenix.com
Mon May 11 11:22:09 CEST 2015

On 11.05.2015 11:13, Nick Coghlan wrote:

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.

The env var would not be read at Python startup time, only when loading the ssl module, so the -E switch would not have the effect of disabling it - unlike the hash seed logic, which is run (and has to be run) at Python startup time.

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)

The Fastly cache seems to be having problems again. I only get: 503 Backend is unhealthy - Details: cache-fra1225-FRA 1431335851 2631441948

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.

Can't we have both ?

I don't think that we can wait for a whole PEP process to run through to fix this regression in 2.7.9.

-- Marc-Andre Lemburg eGenix.com

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 http://www.egenix.com/company/contact/

More information about the Python-Dev mailing list