[Python-Dev] Proposed schedule for 3.4.2

[Jim Baker]

+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 at python.org> wrote:

> 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)
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/jbaker%40zyasoft.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140908/784afd90/attachment.html>