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 firstname.lastname@example.org wrote:
- 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:"
- 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.
- 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. :)
- 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?
- 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.