On 9 Nov 2013 02:41, "Christian Heimes" wrote:
>
> Am 08.11.2013 08:42, schrieb Antoine Pitrou:
> > 3.2 actually, while many code bases are still 2.x-compatible.
> > There's no need to make migration more annoying right now.
>
> There is also no need to hinder and delay future improvements for the
Le 08/11/2013 17:39, Christian Heimes a écrit :
Am 08.11.2013 08:42, schrieb Antoine Pitrou:
3.2 actually, while many code bases are still 2.x-compatible.
There's no need to make migration more annoying right now.
There is also no need to hinder and delay future improvements for the
sake of 2.
Am 08.11.2013 08:42, schrieb Antoine Pitrou:
> 3.2 actually, while many code bases are still 2.x-compatible.
> There's no need to make migration more annoying right now.
There is also no need to hinder and delay future improvements for the
sake of 2.x compatibility. Python 2.7.0 has been released
Le 07/11/2013 22:42, Christian Heimes a écrit :
Am 07.11.2013 21:45, schrieb Antoine Pitrou:
I'm in favour but I think 3.5 is too early. Keep in mind SSLContext is
quite young.
It's available since 3.3
3.2 actually, while many code bases are still 2.x-compatible.
There's no need to make migr
Somehow your mail didn't end up on Python-dev
Am 08.11.2013 00:38, schrieb Nick Coghlan:
> In that case, it sounds like you need *two* new options rather than
> one. "verify_hostname", with the None/True/False behaviour and a
> separate postverify hook.
Mmmh, yes, you are making an intriguing poi
Am 08.11.2013 00:09, schrieb Barry Warsaw:
> I'm sure you're considering this, but I want to explicitly preserve the
> ability to register self-signed certificates. It's often necessary in
> practice, but very useful for testing purposes.
>
> ssl.SSLContext.load_cert_chain() is the way to do this
Am 07.11.2013 23:25, schrieb Nick Coghlan:
> Change this to create_default_context() (to make it clearer there is no
> global context object) and I'm generally +1.
Good idea!
> This overlaps confusingly with "verify_mode". Perhaps just offer a
> module level "verify_hostname" API that adapts betw
On Nov 07, 2013, at 10:42 PM, Christian Heimes wrote:
>You misunderstood me. I'm not proposing a global SSLContext object but a
>factory function that creates a context for Python stdlib modules. Right
>now every urllib, http.client, nntplib, asyncio, ftplib, poplib and
>imaplib have duplicated co
On 8 Nov 2013 04:18, "Christian Heimes" wrote:
>
> Hi,
>
> I'd like to simplify, unify and tighten SSL handling and verification
> code in Python 3.5. Therefore I propose to deprecate some features for
> Python 3.4. SSLContext objects are going to be the central instance for
> configuration.
>
> I
On Nov 7, 2013, at 4:42 PM, Christian Heimes wrote:
>>>
>>> - deprecate implicit verify_mode=CERT_NONE. Python 3.5 will default
>>> to CERT_REQUIRED.
>>
>> -0.9. This breaks compatibility and doesn't achieve anything, since
>> there's no reliable story for CA certs.
>
> I'd like to move to
Am 07.11.2013 21:45, schrieb Antoine Pitrou:
> I'm in favour but I think 3.5 is too early. Keep in mind SSLContext is
> quite young.
It's available since 3.3
>> - deprecate implicit verify_mode=CERT_NONE. Python 3.5 will default
>>to CERT_REQUIRED.
>
> -0.9. This breaks compatibility and doe
Le 07/11/2013 19:13, Christian Heimes a écrit :
Hi,
I'd like to simplify, unify and tighten SSL handling and verification
code in Python 3.5.
Therefore I propose to deprecate some features for
Python 3.4. SSLContext objects are going to be the central instance for
configuration.
In order to ar
Hi,
I'd like to simplify, unify and tighten SSL handling and verification
code in Python 3.5. Therefore I propose to deprecate some features for
Python 3.4. SSLContext objects are going to be the central instance for
configuration.
In order to archive the goal I propose to
- deprecate the key_fi
13 matches
Mail list logo
