[Python-Dev] Proposed schedule for 3.4.2 (original) (raw)

Guido van Rossum guido at python.org
Mon Sep 8 18:58:21 CEST 2014

On Mon, Sep 8, 2014 at 5:08 AM, Nick Coghlan <ncoghlan at 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140908/66262f12/attachment.html>

More information about the Python-Dev mailing list