On Sat, 30 Aug 2014 14:03:57 +0200, "M.-A. Lemburg" <m...@egenix.com> wrote: > On 30.08.2014 12:55, Antoine Pitrou wrote: > > On Sat, 30 Aug 2014 12:46:47 +0200 > > "M.-A. Lemburg" <m...@egenix.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. --David _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
