On 11.05.2015 11:13, Nick Coghlan wrote: > On 11 May 2015 at 18:04, M.-A. Lemburg <m...@egenix.com> wrote: >> On 10.05.2015 05:04, Robert Collins wrote: >>> On 10 May 2015 at 11:44, Chris Angelico <ros...@gmail.com> wrote: >>>> On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg <m...@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/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com