+1 for the suggested change to 2.7. Something I have put off in the work on SSL support in Jython 2.7 is what to do about the possibility of adding a large security hole to support standard Python behavior here with CERT_NONE. By default, we use the standard trust database and corresponding manager from Java, as augmented by any provided ca_certs. In practice, I don't think people are really noticing that it's currently locked down in the latest beta, which added this SSL support.
Although it's very easy to open such a hole on Jython/Java, it's much nicer if we require the user has to do some work to do so, and on a per connection basis. - Jim On Mon, Sep 8, 2014 at 10:58 AM, Guido van Rossum <gu...@python.org> wrote: > 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/jbaker%40zyasoft.com > >
_______________________________________________ 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
