[PATCH STABLE] sslutil: restore old behavior not requiring a hostname argument (issue5210)

Gregory Szorc gregory.szorc at gmail.com
Sat Apr 30 16:27:20 UTC 2016


# HG changeset patch
# User Gregory Szorc <gregory.szorc at gmail.com>
# Date 1462033607 25200
#      Sat Apr 30 09:26:47 2016 -0700
# Branch stable
# Node ID bad58049b1a877a9136c2380b98b12a8a1fbe2a4
# Parent  cbf282da720ac907b492a2b1045288130d6d166e
sslutil: restore old behavior not requiring a hostname argument (issue5210)

This effectively backs out changeset 1fde84d42f9c.

The http library behind ui.http2=true isn't specifying the hostname.
It is the day before the expected 3.8 release and we don't want to ship
a regression.

I'll try to restore this requirement in the 3.9 release cycle as part
of planned improvements to Mercurial's SSL/TLS interactions.

diff --git a/mercurial/sslutil.py b/mercurial/sslutil.py
--- a/mercurial/sslutil.py
+++ b/mercurial/sslutil.py
@@ -115,19 +115,16 @@ def wrapsocket(sock, keyfile, certfile, 
 
     In addition to the arguments supported by ``ssl.wrap_socket``, we allow
     the following additional arguments:
 
     * serverhostname - The expected hostname of the remote server. If the
       server (and client) support SNI, this tells the server which certificate
       to use.
     """
-    if not serverhostname:
-        raise error.Abort('serverhostname argument required')
-
     # Despite its name, PROTOCOL_SSLv23 selects the highest protocol
     # that both ends support, including TLS protocols. On legacy stacks,
     # the highest it likely goes in TLS 1.0. On modern stacks, it can
     # support TLS 1.2.
     #
     # The PROTOCOL_TLSv* constants select a specific TLS version
     # only (as opposed to multiple versions). So the method for
     # supporting multiple TLS versions is to use PROTOCOL_SSLv23 and


More information about the Mercurial-devel mailing list