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

[Nick Coghlan]

On 26 November 2015 at 05:57, Barry Warsaw <barry at python.org> wrote:
> There's a lot to process in this thread, but as I see it, the issue breaks
> down to these questions:
>
> * How should PEP 493 be implemented?
>
> * What should the default be?
>
> * How should PEP 493 be worded to express the right tone to redistributors?
>
> Let me take on the implementation details here.
>
> On Nov 24, 2015, at 04:04 PM, M.-A. Lemburg wrote:
>
>>I would still find having built-in support for the recommendations
>>in the Python stdlib a better approach
>
> As would I.
>
> Currently the PEP contains some sample code for reading a configuration file
> and an environment variable, and assigning the default behavior based on these
> values.
>
> The first improvement to the stdlib I would have made would have been to add
> a convenience function to ssl to enable and disable the verification.
> Something like this:
>
>     def ssl.verify_certificates(enable)
>
> Then at the simplest level, an application that wants to enable higher
> security could do this early in its main entry point:
>
>     import ssl
>     if hasattr(ssl, 'verify_certificates'):
>         ssl.verify_certificates(True)
>
> or
>
>     ...
>         ssl.verify_certificates(False)
>
> and that would work regardless of the platform default, and it would work
> properly on older versions of Python 2.7 that didn't have the backport.  This
> seems so straightforward, I'm wondering why PEP 493 doesn't consider it.

PEP 476 rejected providing a public indefinitely maintained API for
this, so PEP 493 is specifically about helping commercial
redistributors offer a smoother transition plan to customers without
affecting the public Python level API, and without encouraging a
plethora of mutually incompatible transition schemes.

> I would like to see the sample code in PEP 493 implemented in the stdlib.  It
> would then be a matter of cherry picking that should a distro decide to
> backport it.  It means one less non-trivial delta from upstream which has to
> be managed separately.  The only difference to the combined approach I'd make
> is to handle the case where the _cert_verification_config file doesn't exist.
>
> (If you included the convenience method above, then the sample code could be
> simplified down to a default for the `enable` parameter and a call to
> ssl.verify_certificates().)
>
> Is it too late to include both of those suggestions in PEP 493 and Python
> 2.7.11?

PEP 493 isn't about attempting to rehash the PEP 476 discussions in
search of a different conclusion, so this would need to be a different
PEP, preferably one that targets Python 3.6 first and covers more than
just HTTPS.  Such an API could then be considered as a backport
candidate for 2.7.12. (2.7.11rc1 has already been published, so there
isn't any scope for updates there). I actually think that's a nicer
approach, but also think the recommendations in PEP 493 are much
simpler to implement and test, while still meeting the bar of "good
enough to solve the problem at hand".

If anyone does decide to write that PEP, then the fact that SELinux
offers "setenforce 0" and AppArmor can be turned off with a kernel
boot option can be used as examples of platform developers letting end
users make their own security decisions, even if the platform provider
recommends leaving the more opinionated default behaviour enabled.

Cheers,
Nick.

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