On Mon, Sep 8, 2014 at 5:08 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > It would also be good to get Guido's official verdict on PEP 476 (the > switch to validating HTTPS by default) in time for 3.4.2. Based on the > previous discussion, Alex updated the PEP to suggest "just fix it" for > all of 3.5, 3.4.x and 2.7.x (including the httplib SSLContext support > backport in the latter case). > My opinion hasn't changed since the last time I opened my mouth prematurely. :-) I would very much like these to go in, but for 2.7 I am now worried about what we should tell people who have a script that uses an https URL to access a service that can only be accessed via SSL/TLS to a self-signed or otherwise mis-configured cert. I am not insisting on an environment variable to disable this (too easy) but I do think it must be possible to make a simple change to the code, on the order of tracking down the urlopen() call and adding a new keyword parameter. Such a band-aid needn't be backward compatible (we can introduce a new keyword parameter for this purpose) and it needn't be totally straightforward (we can assume some modicum of understanding of finding and editing .py files) but it should definitely not require a refactor of the script (e.g. swapping out urlopen and replacing it with httplib or requests would be too much of a burden). And we should have prominent documentation (perhaps in FAQ form?) with an example of how to do it. > I think that would be feasible with an rc on the 20th, but challenging > if the rc is this coming weekend. > > Note, as I stated in the previous thread, I'm now +1 on that PEP, > because I don't see any way to write an automated scan for a large > code base that ensures we're not relying on the default handling at > all. If the default behaviour is to validate HTTPS, the lack of such a > scanner isn't a problem - any failures to cope with self-signed or > invalid certs will be noisy, and we can either fix the certs, patch > the code to cope with them appropriately, or (for the self-signed cert > case) configure OpenSSL via environment variables. If dealing with > invalid certs is truly necessary, and the code can't be updated > either, then I'm OK with the answer being "keep using an older version > of Python, as that's going to be the least of your security concerns". > Yeah, I am not interested in helping out the case where the user is incapable (for whatever reason) of tracking down and changing a couple of lines of code. Such users are dependent on someone else with wizard powers anyway (who gave them the script?). -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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
