[Python-Dev] PYTHONHTTPSVERIFY env var

[M.-A. Lemburg]

On 09.05.2015 02:29, Nick Coghlan wrote:
> On 8 May 2015 8:14 pm, "M.-A. Lemburg" <mal at egenix.com> wrote:
>>
>> On 08.05.2015 11:36, Nick Coghlan wrote:
>>> On 8 May 2015 6:52 pm, "M.-A. Lemburg" <mal at egenix.com> wrote:
>>>>
>>>> On 07.05.2015 04:30, Nick Coghlan wrote:
>>>>>> Can we please make the monkeypatch a regular part of Python's
>>>>>> site.py which can enabled via an environment variable, say
>>>>>> export PYTHONHTTPSVERIFY=0.
>>>>>>
>>>>>> See http://bugs.python.org/issue23857 for the discussion.
>>>>> ...
>>>>> I actually do think it would be good to have such a feature as a
>>>>> native part of Python 2.7 in order to provide a nicer "revert to the
>>>>> pre-PEP-476 behaviour" experience for Python 2.7 users (leaving the
>>>>> "there's no easy way to turn HTTPS certificate verification off
>>>>> globally" state of affairs to Python 3), but I don't currently have
>>>>> the time available to push for that against the "end users can't be
>>>>> trusted not to turn certificate verification off when they should be
>>>>> fixing their certificate management instead" perspective.
>>>>
>>>> We're currently working on a new release of eGenix PyRun and this
>>>> will include Python 2.7.9.
>>>>
>>>> We do want to add such an env switch to disable the cert verification,
>>>> so would like to know whether we can use PYTHONHTTPSVERIFY for this
>>>> or not.
>>>
>>> That's a slightly misleading quotation of my post, as I'm opposed to the
>>> use of an environment variable for this, due to the fact that using the
>>> "-E" switch will then revert to the upstream default behaviour of
> verifying
>>> certificates, rather defeating the point of introducing the legacy
>>> infrastructure compatibility feature in the first place.
>>
>> Oh, sorry. I read your email implying that you are fine with
>> the env var approach.
>>
>> I don't really see the issue with -E, though. It's well possible
>> to internally set PYTHONHTTPSVERIFY=0 when -E is used to regain
>> backwards compatibility per default for Python 2.7.
>>
>> Regarding the config file approach and letting distributions
>> set their own defaults:
>>
>> I don't think it's a good idea to have one distribution
>> default to verifying HTTPS certs via a global config file
>> and another distribution do the opposite.
>>
>> Python itself should define the defaults to be used, not
>> the distributions.
> 
> As a result of the discussions around both PEP 466 and 476, I'm now firmly
> of the view that it's correct for the upstream Python community to assume
> the public internet as its standard operating environment when it comes to
> network security settings, and for those of us working for commercial
> redistributors to subsequently bear the cost of adapting from that upstream
> assumption to the different assumptions that may apply in the context of
> organisational intranets.
> 
> That's also why I've come around to the view that an informational PEP with
> recommendations for redistributors, rather than an actual change to Python
> 2.7, is the right answer (at least initially) when it comes to providing a
> smoother transition plan for PEP 476 - the folks saying "it's a bad idea to
> make this easy to turn off" are *right* from the perspective of operating
> over the public internet, or with well designed internal SSL/TLS
> certificate management, it's just also a *necessary* idea (in my view) to
> help CIOs and other infrastructure leads responsibly and effectively manage
> the wide range of risks associated with internal infrastructure upgrades.

I don't agree. We've broken the contract that people had with Python 2.7
by introducing a major breakage in a patch level release very far
down the line in 2.7.9, without providing an easy and official
way to opt-out that does not involve hacking your installation.

IMO, we should not fall for the somewhat arrogant view that
we know better than all the Python users out there when it
comes to running secure systems.

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.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 09 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/