On Tue, Sep 9, 2014 at 12:11 PM, Christian Heimes firstname.lastname@example.org wrote:
On 09.09.2014 05:03, Nick Coghlan wrote:
On 9 Sep 2014 10:48, "Jim J. Jewett" <email@example.com mailto:firstname.lastname@example.org> 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):
- "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.