On Wed, 22 Jan 2014 15:13:00 +0100 Christian Heimes <christ...@python.org> wrote: > On 22.01.2014 13:43, Jesse Noller wrote: > > I have to concur with Donald here - in the case of security, especially > > language security which directly impacts the implicit security of > > downstream applications, I should not have to opt in to the most secure > > defaults. > > > > Yes; this potentially breaks applications relying on insecure / loose > > defaults. However it changes the model to "you are by default, explicitly > > secure" then relying on the domain knowledge of an application developer to > > harden their application. > > > > When, if this changes, an application breaks, it will be in a plainly > > obvious way which can quickly be resolved. > > > > Donald is perfectly right: today, it's trivial to MITM an application that > > relies off of the current behavior; this is bad news bears for users and > > developers as it means they need domain knowledge to secure their > > applications by default they may not have. > > For 3.5 I'd like to work on a policy framework for the ssl where > application can define policies like SSL/TLS version, cert store, > verification modes etc. etc.
Isn't that called a SSLContext? _______________________________________________ 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
