[Python-Dev] PYTHONHTTPSVERIFY env var

Nick Coghlan ncoghlan at gmail.com
Tue May 12 10:56:07 CEST 2015


On 12 May 2015 at 17:57, M.-A. Lemburg <mal at egenix.com> wrote:
> The point here is that sys admins should not
> have to patch Python to make things work again, in case
> an application is not prepared for the certificate
> verification - which is rather likely, since the pre-Python
> 2.7.9 doesn't even provide the necessary APIs to pass
> certificate locations to urllib or urllib2.

You've persuaded me that we should describe *both* configuration
mechanisms in the recommendations PEP (one for a cross-platform
environment variable based approach that also works for embedded
Python instances and user level distributions, one for a configuration
file based approach that only covers *nix system Python
installations), and leave the decision to redistributors as to which
approach makes the most sense for their particular audience.

Neither goes into upstream CPython 2.7, and neither goes into any
version of Python 3.

>> Yes, getting an administrative application to the point where -S can
>> be used means getting it to a point where it has *no* Python
>> dependencies outside the standard library. It can certainly be done,
>> but often won't be worth the hassle. As a result, using -s to turn off
>> the user site directory and -E to turn off PYTHONPATH processing are
>> the more common sys.path related hardening techniques in Python 2.7.
>
> Overall, I find the config file approach a too big a hammer to solve
> this simple problem.

The problem of managing this security issue on behalf of customers
without risking breaking their world is in no way simple - hence why
most redistributors lobbed it into the "too hard" basket instead, and
why we've been discussing possible UX improvements with upstream
on-and-off for a couple of months now :)

> If there were more use cases for a Python config file, the added
> overhead could pay off, but then we should put more thought into
> optimizing the config file load time and probably end up using
> a Python module as config file (which provides these optimizations
> for free).

This is why the proposal is for an SSL specific configuration file,
loaded only when the SSL module is imported.

> In the end, we'd be introducing another sitecustomize.py,
> usercustomize.py and perhaps localcustomize.py - only with
> fixed locations rather than importing them via sys.path.

It won't come to that, as Linux system package managers don't support
any of these - that's what containers are for.

Cheers,
Nick.

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


More information about the Python-Dev mailing list