[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