Re: [Python-Dev] Backwards compatibility after certificate autovalidation

2014-09-09 Thread Nick Coghlan
On 10 September 2014 07:13, Jim J. Jewett wrote: > On Tue, Sep 9, 2014 at 12:11 PM, Christian Heimes > wrote: >> On 09.09.2014 05:03, Nick Coghlan wrote: >>> >>> On 9 Sep 2014 10:48, "Jim J. Jewett" >> > wrote: >>> From Guido's and your feedback, I think we may need

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

2014-09-09 Thread Jim J. Jewett
On Tue, Sep 9, 2014 at 12:11 PM, Christian Heimes wrote: > On 09.09.2014 05:03, Nick Coghlan wrote: >> >> On 9 Sep 2014 10:48, "Jim J. Jewett" > > wrote: >> From Guido's and your feedback, I think we may need two things to >> approve this for 3.4.2 (putting 2.7 aside f

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

2014-09-09 Thread Nick Coghlan
On 10 Sep 2014 02:11, "Christian Heimes" wrote: > > On 09.09.2014 05:03, Nick Coghlan wrote: > > > > On 9 Sep 2014 10:48, "Jim J. Jewett" > > wrote: > >> I assume that adding _unverified_urlopen or urlopen(context=...) do > >> provide incremental improvements compatib

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

2014-09-09 Thread Christian Heimes
On 09.09.2014 05:03, Nick Coghlan wrote: > > On 9 Sep 2014 10:48, "Jim J. Jewett" > wrote: >> I assume that adding _unverified_urlopen or urlopen(context=...) do >> provide incremental improvements compatible with the eventual full >> opt-in. If so, adding them is pr

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

2014-09-08 Thread Donald Stufft
It’s create_default_context() -> https://docs.python.org/3.4/library/ssl.html#ssl.create_default_context > On Sep 8, 2014, at 11:40 PM, Guido van Rossum wrote: > > The multiple threads going on are confusing (or maybe GMail makes them more > confusing), but the architecture you are sketching

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

2014-09-08 Thread Guido van Rossum
The multiple threads going on are confusing (or maybe GMail makes them more confusing), but the architecture you are sketching here sounds good. I can't find get_default_context() in the repo, but perhaps I need to refresh, or perhaps you're talking about a design in a PEP. On Mon, Sep 8, 2014 at

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

2014-09-08 Thread Nick Coghlan
On 9 Sep 2014 10:48, "Jim J. Jewett" wrote: > I assume that adding _unverified_urlopen or urlopen(context=...) do > provide incremental improvements compatible with the eventual full > opt-in. If so, adding them is probably reasonable, but I think the > PEP should explicitly list all such approve

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

2014-09-08 Thread Jim J. Jewett
On Mon, Sep 8, 2014 at 3:44 PM, Cory Benfield wrote: > On 8 September 2014 18:23, Jim J. Jewett wrote: >> Summary: There needs to be a simple way to opt out at install time. >> It would be far better to offer more fine-grained control, but leaving >> that better solution to downstream is accepta

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

2014-09-08 Thread Nick Coghlan
On 9 Sep 2014 03:25, "Jim J. Jewett" wrote: > Examples of good enough: > "Add this file to site-packages" > "Add this environment variable with this setting" > "Add this command line switch to your launch script" The monkeypatching hack I proposed would work correctly in sitecustomize

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

2014-09-08 Thread Cory Benfield
On 8 September 2014 18:23, Jim J. Jewett wrote: > Summary: There needs to be a simple way to opt out at install time. > It would be far better to offer more fine-grained control, but leaving > that better solution to downstream is acceptable. Does this argument apply to a hypothetical 2.7 backpo

[Python-Dev] Backwards compatibility after certificate autovalidation

2014-09-08 Thread Jim J. Jewett
Summary: There needs to be a simple way to opt out at install time. It would be far better to offer more fine-grained control, but leaving that better solution to downstream is acceptable. On 3 September 2014 01:19, Antoine Pitrou wrote: > RFC 2818 (HTTP over TLS) has the following language