On 30.08.2014 15:32, R. David Murray wrote:
On Sat, 30 Aug 2014 14:03:57 +0200, "M.-A. Lemburg" firstname.lastname@example.org wrote:
On 30.08.2014 12:55, Antoine Pitrou wrote:
On Sat, 30 Aug 2014 12:46:47 +0200 "M.-A. Lemburg" email@example.com 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.
That would be a possibility as well, yes.
I'd just like to see a way to say: I know what I'm doing and I'm not in the mood to configure my own CA list, so please go ahead and accept whatever certs you find -- much like what --no-check-certificate does for wget.