<div dir="ltr"><div>+1 for the suggested change to 2.7.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>- Jim</div><div><br></div><div> </div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 8, 2014 at 10:58 AM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Sep 8, 2014 at 5:08 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
</span>It would also be good to get Guido's official verdict on PEP 476 (the<br>
switch to validating HTTPS by default) in time for 3.4.2. Based on the<br>
previous discussion, Alex updated the PEP to suggest "just fix it" for<br>
all of 3.5, 3.4.x and 2.7.x (including the httplib SSLContext support<br>
backport in the latter case).<br></blockquote><div><br></div></span><div>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.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think that would be feasible with an rc on the 20th, but challenging<br>
if the rc is this coming weekend.<br>
<br>
Note, as I stated in the previous thread, I'm now +1 on that PEP,<br>
because I don't see any way to write an automated scan for a large<br>
code base that ensures we're not relying on the default handling at<br>
all. If the default behaviour is to validate HTTPS, the lack of such a<br>
scanner isn't a problem - any failures to cope with self-signed or<br>
invalid certs will be noisy, and we can either fix the certs, patch<br>
the code to cope with them appropriately, or (for the self-signed cert<br>
case) configure OpenSSL via environment variables. If dealing with<br>
invalid certs is truly necessary, and the code can't be updated<br>
either, then I'm OK with the answer being "keep using an older version<br>
of Python, as that's going to be the least of your security concerns".<br></blockquote></span></div><br></div><div class="gmail_extra">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?).<span class="HOEnZb"><font color="#888888"><br clear="all"></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)
</div></font></span></div>
<br>_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/jbaker%40zyasoft.com" target="_blank">https://mail.python.org/mailman/options/python-dev/jbaker%40zyasoft.com</a><br>
<br></blockquote></div><br><div><br></div><div dir="ltr"><div></div></div>
</div></div>