(Oops, I had a version of this reply sitting in my Drafts folder for a week, and only noticed after pushing the most recent PEP update that it had never been sent)
On 1 December 2015 at 06:32, Barry Warsaw email@example.com wrote:
On Nov 27, 2015, at 04:04 PM, Nick Coghlan wrote:
New draft pushed: https://hg.python.org/peps/rev/f602a47ea795
This is a significant rewrite that switches the PEP to a Standards Track PEP proposing two new features for 2.7.12+: an "ssl._verify_https_certificates()" configuration function, and a "PYTHONHTTPSVERIFY" environment variable (although writing them together like that makes me wonder if the latter should now be "PYTHONVERIFYHTTPS" instead).
Thanks for this, and +1 on Stephen's suggested name change (which you've already pushed).
Two comments: the PEP still describes the configuration file implementation. Is this slated for 2.7.12 also? If not, should it just be dropped from the PEP?
That recommendation is still needed to backport PEP 476 itself to versions prior to 2.7.9 - otherwise there's no way to flip the default from "don't verify" to "verify" for the entire Python installation. It may be that the system Python in RHEL/CentOS 7 and derivatives ends up being the only case where that happens (since that's the only instance I'm aware of with a 2024 support deadline, rather than 2019 or earlier), but if anyone else does do it, it would be preferable if they adopted the same approach to configuring it.
However, I just pushed an update that reverses the presentation order of the two main backporting sections: https://hg.python.org/peps/rev/17e0e36cbc19
The original order came from the point where this was just an Informational PEP suggesting some backporting techniques, but now that it suggests some actual upstream changes for 2.7.12+, it makes more sense to cover those first, and then be more explicit that it's acceptable to skip implementing the rest of the PEP entirely.
Accordingly, that change also includes the following new paragraph in the section on the PEP 476 backport:
================ This PEP doesn't take a position on whether or not this particular change is a good idea - rather, it suggests that *if* a redistributor chooses to go down the path of making the default behaviour configurable in a version of Python older than Python 2.7.9, then maintaining a consistent approach across redistributors would be beneficial for users. ================
I'd mildly prefer no default value for `enable` in _https_verify_certificates(). I'd have preferred a keyword-only argument, but of course this is Python 2. Instead, I'd like to force passing True or False (and document using `enable=True` or `enable=False`) and not rely on a default argument. But I'm only +0 on that detail.
My rationale for giving it a default is to make it marginally more straightforward to turn verification on than it is to turn it off. That's going to be most relevant in the pre-2.7.9 backport case, since in 2.7.9+ the HTTPS certificate verification will already be on by default.