This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Lukasa, alex, christian.heimes, dstufft, giampaolo.rodola, janssen, martin.panter, ncoghlan, orsenthil, vstinner
Date 2016-09-10.09:04:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
+1 for a common note in all affected modules along the lines of "An appropriately configured SSLContext should be provided for any use cases that involve accepting self-signed certificates, privately signed certificates, or any other kind of certificate that won't validate against the default system certificate trust store.

It is expected that a future version of Python will switch to explicitly verifying SSL certificates for all SSL/TLS protected connections by default (due to the widespread use of self-signed and privately signed certificates for other protocols, full verification is currently the default only for HTTPS)."

Regarding ssl.wrap_socket(), would it be feasible to provide a migration path to a situation where that's just a thin wrapper around ssl.get_default_context().wrap_socket()?

Comparing the parameter lists:

>>> module_params - method_params
{'ciphers', 'keyfile', 'ca_certs', 'ssl_version', 'cert_reqs', 'certfile'}
>>> method_params - module_params

That means the real problems are the ciphers, keyfile, ca_certs, ssl_version, cert_reqs and certfile parameters and the internal use of SSLContext() rather than get_default_context(), rather than the essential idea of providing a shorthand spelling for "wrap a socket with the default SSL/TLS settings".
Date User Action Args
2016-09-10 09:04:33ncoghlansetrecipients: + ncoghlan, janssen, orsenthil, vstinner, giampaolo.rodola, christian.heimes, alex, martin.panter, dstufft, Lukasa
2016-09-10 09:04:33ncoghlansetmessageid: <>
2016-09-10 09:04:33ncoghlanlinkissue28022 messages
2016-09-10 09:04:32ncoghlancreate