(capturing these details here for now, we should at least have a python-dev discussion before going ahead with any changes in this area)

The additional background here is that we started looking closely at what would be involved in applying PEP 476 to systems where there are 3 parties involved and the aim is to tweak the system Python to require explicitly opting in to certificate verification (at least for the time being):

* CPython upstream verifies certificates by default
* Platform vendor configures Python to use legacy mode by default
* System administrator responsible for the machine can easily opt in to global verification and have that setting persist through Python updates

The opt out solution in PEP 476 works for the "direct consumption of upstream" case, as the system administrator responsible for the machine can opt out globally in sitecustomize.py.

It turns out that solution *doesn't* work at the platform vendor level, as sitecustomize.py is intended for use by the system administrator responsible for the machine - providing it as a platform vendor would be the wrong thing to do from a packaging perspective, as that usage would conflict with the intended use case of local site customisation.

We suspected this would be a problem when we were discussing PEP 476 (hence the discussions of configuration files that Victor linked), but decided to postpone further consideration until after the distros had had a chance to consider the problem in more detail.

Patching httplib to have a different default from CPython upstream isn't desirable, as that would perpetuate the problem that PEP 476 was designed to fix with no clear migration path to more secure defaults as the platform level.

The idea of this patch is to provide a middle ground where a configuration file can be provided with the system python package that preserves the pre-PEP-476 status quo by setting "verify=disable" for https verification. If the configuration file is missing entirely then the upstream default of verifying certificates would still be used.

The "verify=enable" setting would then let system administrators explicitly opt in to certificate verification, while "verify=platform_default" would mean "verify=disable" while the default package configuration still did that, but would potentially switch to meaning "verify=enable" at some point in the future (the exact meaning of the "platform_default" setting would likely be controlled by a distro level patch anyway, so it could potentially be omitted from the upstream change proposal).

From an implementation perspective, the reason the proposal is for a global HTTPS switch rather than a fine-grained per-module setting is back the follow-up proposal would be to write a PEP to backport it to Python 2.7, so something that's closely aligned with the existing opt-out mechanism in PEP 476 is considered desirable.