On 30 Apr 2015 5:59 pm, "M.-A. Lemburg" <m...@egenix.com> wrote:
> On 30.04.2015 02:33, Nick Coghlan wrote: > > Hi folks, > > > > This is just a note to highlight the fact that I tweaked the "Opting > > out" section in PEP 476 based on various discussions I've had over the > > past few months: https://hg.python.org/peps/rev/dfd96ee9d6a8 > > > > The notable changes: > > > > * the example monkeypatching code handles AttributeError when looking > > up "ssl._create_unverified_context", in order to accommodate older > > versions of Python that don't have PEP 476 implemented > > * new paragraph making it clearer that while the intended use case for > > the monkeypatching trick is as a workaround to handle environments > > where you *know* HTTPS certificate verification won't work properly > > (including explicit references to sitecustomize.py and Standard > > Operating Environments for Python), there's also a secondary use case > > in allowing applications to provide a system administrator controlled > > setting to globally disable certificate verification (hence the change > > to the example code) > > * new paragraph making it explicit that even though we've improved > > Python's default behaviour, particularly security sensitive > > applications should still provide their own context rather than > > relying on the defaults > > Can we please make the monkeypatch a regular part of Python's > site.py which can enabled via an environment variable, say > export PYTHONHTTPSVERIFY=0. > > See http://bugs.python.org/issue23857 for the discussion. > > Esp. for Python 2.7.9 the default verification from PEP 476 > is causing problems for admins who want to upgrade their > Python installation without breaking applications using > Python. They need an easy and official non-hackish way to > opt-out from the PEP 476 default on a per application basis. My current recommendation to the Red Hat Python team is to put together a draft PEP 394 style informational PEP to define a documented configuration file based approach that redistributors may choose to implement in order to provide a smoother transition path for their end users: https://bugzilla.redhat.com/show_bug.cgi?id=1173041#c8 The problem I identified with reusing the environment variable based approach that we used with hash randomisation is that "-E" turns the upstream default behaviour back on. That was acceptable for hash randomisation, but would be too limiting here (as the appropriate value for the HTTPS certificate verification configuration setting relates primarily to the general state of SSL/TLS certificate management in the environment where Python is being deployed, moreso than to the specific networked applications that are being run). I actually do think it would be good to have such a feature as a native part of Python 2.7 in order to provide a nicer "revert to the pre-PEP-476 behaviour" experience for Python 2.7 users (leaving the "there's no easy way to turn HTTPS certificate verification off globally" state of affairs to Python 3), but I don't currently have the time available to push for that against the "end users can't be trusted not to turn certificate verification off when they should be fixing their certificate management instead" perspective. Cheers, Nick. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
