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 <christ...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com