(original) (raw)
+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 <guido@python.org> wrote:
On Mon, Sep 8, 2014 at 5:08 AM, Nick Coghlan <ncoghlan@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?).
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
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