Nick Coghlan added the comment:
+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
{'server_hostname'}
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".
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28022>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
