[Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

[Nick Coghlan]

Updated version of the PEP posted: https://hg.python.org/peps/rev/8decac213ebf

On 24 November 2015 at 05:35, Christian Heimes <christian at python.org> wrote:
> 1) The example implementation of the function doesn't check the
> sys.flags.ignore_environment. Internally CPython has specialized getenv
> function that ignores env vars with PYTHON prefix when the flag is set.
> PYTHON* env vars aren't removed from os.environ. Modules have to check
> the flag.

I guarded the relevant sections in the examples with "if not
sys.flags.ignore_environment:"

> 2) The PEP is rather Linux-centric. What's the recommended path to the
> config file on other platforms like BDS (/usr/local/etc/ is preferred
> for additional dependencies on FreeBSD), OSX and Windows?

The environment variable section should be generic, and the
configuration file section is largely specific to vendors offering
long term commercial support options for Linux distros.

There was already a qualification in the "Recommended file location"
section limiting the scope to *nix systems, so rather than trying to
cover non-Linux systems, I've instead updated that qualification to
limit the recommendation even further to specifically Linux systems.
If *BSD folks pipe up saying they'd like to be included, then adding
another filename recommendation wouldn't be difficult.

> 3) What's the interaction between the location of the config file and
> virtual envs? Would it make sense to search for the file in a venv's
> etc/ first and then dispatch to global /etc/? That way venvs can
> influence the setting, too.

This is a system level configuration setting to preserve backwards
compatible behaviour in the system Python, so scoping it at the
interpreter level was a deliberate design decision. However, I added a
new section to both recommendations describing the lack of interaction
with virtual environments.

> 4) It makes sense to make the cert-verification.cfg file future-proof
> and reserve it for other cert-related configuration in the future. For
> example it could be used to define new contexts, set protocols, ciphers
> or hashes for cert pinning. It should be enough to say that CPython
> reserves the right to add more sections and keys later.

For future releases, I think a different filename makes sense, as we
don't really want a global "turn off HTTPS certificate verification"
flag. Perhaps something like "/etc/python/network-security.cfg", for
example.

> 5) I'm not particular fond of the section name [https]. For one It is
> ambiguous because it doesn't distinguish between server certs and client
> certs.

I added a note to clarify that the section name comes from the "https"
URL schema passed to the relevant client APIs.

> It's also not correct. The default context is used for other
> protocols like imap, smtp etc. over TLS.

That changed in PEP 476 - there's a separate private context for HTTPS
standard library clients now, which allows HTTPS to verify hostnames
by default, while other clients are still permissive. This is noted in
PEP 476: https://www.python.org/dev/peps/pep-0476/#other-protocols

The reason for this is that browsers have provided a pretty good
forcing function in getting folks to use properly signed certificates,
at least on the public internet, but self-signed and improperly signed
certificates are still significantly more common for other protocols.

Cheers,
Nick.

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