[Python-Dev] Proposed schedule for 3.4.2

[Guido van Rossum]

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>