[Python-Dev] PYTHONHTTPSVERIFY env var

[M.-A. Lemburg]

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/