> On 27 Nov 2015, at 06:04, Nick Coghlan <ncogh...@gmail.com> wrote: > > Feature: Configuration API > ========================== > > This change is proposed for inclusion in CPython 2.7.12 and later CPython > 2.7.x > releases. It consists of a new ``ssl._verify_https_certificates()`` to specify > the default handling of HTTPS certificates in standard library client > libraries. > > It is not proposed to forward port this change to Python 3, so Python 3 > applications that need to support skipping certificate verification will still > need to define their own suitable security context. > > Feature detection > ----------------- > > The marker attribute on the ``ssl`` module related to this feature is the > ``ssl._verify_https_certificates`` function itself. > > Specification > ------------- > > The ``ssl._verify_https_certificates`` function will work as follows:: > > def _verify_https_certificates(enable=True): > """Verify server HTTPS certificates by default?""" > global _create_default_https_context > if enable: > _create_default_https_context = create_default_context > else: > _create_default_https_context = _create_unverified_context > > If called without arguments, or with ``enable`` set to a true value, then > standard library client modules will subsequently verify HTTPS > certificates by default, otherwise they will skip verification.
Perhaps I missed this, Nick, but what happens if multiple third party libraries apply updates to call this function in incompatible ways? For example, if you depend on libfoo which calls ssl._verify_https_certificates(False) and libbar which calls ssl._verify_https_certificates(True)? Is it…last import wins?
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
