This sounds great, but the disable switch worries me if it's an ENVVAR=1 kind of deal. Those switches have a tendency on Windows of becoming "well known tricks" and they get set globally and permanently, often by application installers or sysadmins (PYTHONPATH suffers the exact same problem).

It sounds like the likely approach is a certificate name, which is fine, provided there's no option for "accept everything". I just wanted to get an early vote in against a boolean switch.


Top-posted from my Windows Phone

From: R. David Murray
Sent: 8/30/2014 6:33
Subject: Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Sat, 30 Aug 2014 14:03:57 +0200, "M.-A. Lemburg" <> wrote:
> On 30.08.2014 12:55, Antoine Pitrou wrote:
> > On Sat, 30 Aug 2014 12:46:47 +0200
> > "M.-A. Lemburg" <> wrote:
> >>> That use case should be served with the SSL_CERT_DIR and SSL_CERT_FILE
> >>> env vars (or, better, by specific settings *inside* the application).
> >>>
> >>> I'm against multiplying environment variables, as it makes it more
> >>> difficult to assess the actual security of a setting. The danger of an
> >>> ill-secure setting is much more severe than with hash randomization.
> >>
> >> You have a point there. So how about just a python run-time switch
> >> and no env var ?
> >
> > Well, why not, but does it have a value over letting the code properly
> > configure their SSLContext?
> Yes, because when Python changes the default to be validating
> and more secure, application developers will do the same as
> they do now: simply use the defaults ;-)

But neither of those addresses the articulated use case: someone *using*
a program implemented in python that does not itself provide a way to
disable the new default security (because it is *new*).  Only an
environment variable will do that.

Since the environment variable is opt-in, I think the "consenting
adults" argument applies to Alex's demure about "multiple connections".
It could still emit the warnings.

Python-Dev mailing list