Updated version of the PEP posted: https://hg.python.org/peps/rev/8decac213ebf On 24 November 2015 at 05:35, Christian Heimes <christian@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@gmail.com | Brisbane, Australia