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

[Christian Heimes]

On 2015-11-24 00:47, Nick Coghlan wrote:
> 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:"

Thanks!


>> 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.

I mentioned 2) and 3) because I suspect that some people will want to
use the new setting to configure applications. You know how people
think. They get a new shiny tool and then they abuse it as a hammer to
drive in all their problems. :)


>> 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.

Are you planning to remove the "disable verification flag" in the future?


>> 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.

I'm sorry, I forgot about PEP 476 and the separate context function for
HTTPS. Somehow I expected the setting to influence all TLS/SSL
connection, not just HTTPS. I should have read the topic line.

In the light of the new information the setting name makes sense.

Christian