[Python-Dev] Backwards compatibility after certificate autovalidation

[Jim J. Jewett]

On Tue, Sep 9, 2014 at 12:11 PM, Christian Heimes <christian at python.org> wrote:
> On 09.09.2014 05:03, Nick Coghlan wrote:
>>
>> On 9 Sep 2014 10:48, "Jim J. Jewett" <jimjjewett at gmail.com
>> <mailto:jimjjewett at gmail.com>> wrote:
>> From Guido's and your feedback, I think we may need two things to
>> approve this for 3.4.2 (putting 2.7 aside for now):

>> 1. "context" parameter support in urllib.request (to opt out on a
>> per-call basis)
>> 2. a documented way to restore the old behaviour via sitecustomize
>> (which may involve monkeypatching)

> What's with our plan to introduce sslcustomize? Is the idea for a
> configuration module and named contexts off the table?

In a perfect world, half-measures would not be needed, and so neither
would sslcustomize.

In the real world, half-measures are needed, but offering too many of
them adds so much confusion that things can actually get worse in
practice.

In other words, sslcustomize could be great, but getting it wrong
would be a step backwards -- so start it as a 3rd party module.  Since
the biggest users are likely supported customers of downstream
distributions, it makes sense to let them take the lead, though I'm
sure they would appreciate a proof of concept.

> I still prefer the general idea over the monkey patching idea because it
> provides a clean but simple interface for structured configuration.
> Monkey patching of stdlib modules is ugly and error-prone.

The primary use case for monkey patching is to support Separation of
Roles.  (Exact titles will of course differ by business.)

If you need structured configuration, then you are already treating
some calls differently from others, which means that you are already
doing partial remediation.  I agree that monkey patching is the wrong
choice if you are doing partial remediation.

But this partial remediation also implies that a "Developer" and
"Business Owner" are involved to decide which calls need to be
changed, and whether to change the call vs dropping the functionality
vs convincing the owner of the other end of the connection to do
things right in the first place.

A Developer in charge of her own environment doesn't need to monkey
patch -- but she could just do the right thing today, or switch to a
framework that does. sslcustomize may be a really good way for her to
document "these are the strange exceptions in our existing
environment", if it is done right.

A "Deployment Engineer" may not even know python, and is certainly not
authorized to make changes beyond "configuration".  Convincing someone
that a .py file is a configuration knob probably requires an exception
that is painful to get.  (And saying "oh, this is just where we list
security stuff that we're ignoring" won't make it easier.)  Changing
the the urlopen calls would therefore be unacceptable even if source
code were available -- and sometimes it isn't.

The Deployment Engineer is often responsible for upgrading the
infrastructure components (possibly including python) for security
patches, so he has to be able to deploy 3.4.x or 2.7.y (though
*probably* not 3.5.0) without any changes to the application itself --
and usually without access to whatever regression tests the
application itself uses.  (Ideally, someone else who does have that
access is involved, but ... not always.)

What the Deployment Engineer *can* do is modify the environment around
the application.  He can write a shell script that sets environment
variables and or command line options.  He can probably even add a
required component -- which might in practice just be a pre-written
module like sslcustomize, or a .pth file that does the monkey patch on
each launch.  But *adding* such a component is orders of magnitude
simpler (from a bureaucratic perspective) than *modifying* one that
already exists.

The end user often can't do anything outside the application's own UI,
which is why the change has to be handled once at deployment, instead
of as break-fix per call site or per bad certificate.

-jJ