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

[Nick Coghlan]

(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 <barry at python.org> 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.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia