[Python-Dev] PYTHONHTTPSVERIFY env var

Nick Coghlan ncoghlan at gmail.com
Tue May 12 13:10:11 CEST 2015


On 12 May 2015 at 20:56, M.-A. Lemburg <mal at egenix.com> wrote:
> On 12.05.2015 12:04, Donald Stufft wrote:
>>
>>> On May 12, 2015, at 3:57 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>>
>>> In a user based installation (which most applications shipping
>>> their own Python installation are), you can always do this
>>> provided you can gain the application user permissions.
>>
>> Of course, if the application is shipping it’s own Python then
>> it has to actually do something to update to 2.7.9 and it can
>> add it’s own option to disable TLS verification. I personally
>> think that the application providing that option is the *right* way
>> and all these other things are, at best, just temporary shims until
>> the applications do that.
>
> I still believe that requiring to monkeypatch Python is a very poor
> approach in terms of quality software design. We can do better and
> we should.

It's a deliberate design choice to actively discourage people from
doing it - your "Ewww" reaction to monkeypatching is exactly the one
we want. There's no technical reason for people to be bothered by it,
since it's a documented and supported technique covered by the
relevant PEP - it just so happens that the configuration being done is
to switch a function alias between two different functions.

Both of the recommended options I'm putting in the PEP (essentially
the Red Hat design and the eGenix design, since we cover two different
use cases) still adopt that same basic implementation model, they just
provide ways for redistributors to move the configuration inside the
SSL module itself if they decide it is in their users' interests for
them to do so.

Cheers,
Nick.

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


More information about the Python-Dev mailing list