Pythons SSL module verifies that certificates received for HTTPS are valid
according to the specified cacerts, but it doesn't verify that the certificate
is for the host we connect to.
We now explicitly verify that the commonName in the received certificate
matches the requested hostname and is valid for the time being.
This is a minimal patch where we try to fail to the safe side, but we do still
rely on Python's SSL functionality and do not try to implement the standards
fully and correctly. CRLs and subjectAltName are not handled and proxies
haven't been considered.
This change might break connections to some sites if cacerts is specified and
the certificates (by our definition) isn't correct. The workaround is to
disable cacerts which in most cases isn't much worse than it was before with
cacerts.
When using hg commands over an http repository in a long running process, a
httphandler instance is leaked for each command, because of a loop
handler.parent -> OpenerDirector and OpenerDirector.handlers -> handler which
is not handled by Python's gc. Discussion on #mercurial concluded that removing
the __del__ method solved the problem.
Mads Kiilerich pointed out that 1e4ade283b02 was too eager since the
prefix and password keys may contain $-signs. So this only add the
username to the list of keys that are expanded.
This also updates the documentation to match.
Since py3k doesn't have a "file" builtin and, consequently, doesn't support
inheriting from it, this patch refactors the httpsendfile class to wrap the
objects returned by the builtin "open" function while adding the necessary
methods (__len__ for constructing the Content-Length header and read, write,
close and seek for the file-like interface).
On Python 2.6.6 (and patched 2.6.5 on certain Linux distros),
the change that caused issue2255 was also applied to non-digest
authentication; this change extends the 3405cb92c120 fix
accordingly.
Mads Kiilerich pointed out that 1e4ade283b02 was too eager since the
prefix and password keys may contain $-signs. So this only add the
username to the list of keys that are expanded.
This also updates the documentation to match.
This fixes a regression introduced in d5b57915925b when Mercurial reuses the
auth handler for several requests and the redirect counter never is reset.
Python 2.6.5 will keep resetting the retry count on redirects, for example when
the server returns 401 on failing auth (like google code currently does). We
stop the endless recursion by not resetting the count.
http://bugs.python.org/issue3819 introduced the regression with Python 2.6.5.
http://bugs.python.org/issue8797 discusses a fix which might make it to 2.6.6
and 2.7.0.
Recent Pythons (e.g. 2.6.5 and 3.1) introduce a change that causes
urlparse.urlunparse(urlparse.urlparse('x://')) to return 'x:' instead of 'x://'i and
urlparse.urlunparse(urlparse.urlparse('x:///y')) to return 'x:/y' instead of 'x:///y'.
Fix url.hidepassword() and url.removeauth() to handle these cases.
E1101:514:httpshandler._makeconnection: Instance of 'tuple' has no 'pop' member
E1101:516:httpshandler._makeconnection: Instance of 'tuple' has no 'pop' member
Python 2.6.3 introduced HTTPS proxy tunnelling in a way that interferes with
the way HTTPS proxying is handled in Mercurial. This fix generalises it to work
on Python 2.4 to 2.6.
Versions of Python before 2.6 cannot automatically convert a given
port number to an integer, so we add a conversion to coerce the given
input to an int.
This extends the httpshandler with the means to utilise the auth
section to provide it with a PEM encoded certificate key file and
certificate chain file. This works also with sites that both require
client certificate authentication and basic or digest password
authentication, although the latter situation may require the user to
enter the PEM password multiple times.
urllib2 and httplib does not support using CONNECT proxy requests, but
only regular requests over the proxy. This does not work with HTTPS
requests as they typically require that the client issues a CONNECT to
the proxy to give a direct connection to the remote HTTPS server.
This is solved by duplicating some of the httplib functionality and
tying it together with the keepalive library such that a HTTPS
connection that need to be proxied can be proxied by letting a
connection be established to the proxy server and then subsequently
performing the normal request to the specified server through the
proxy server.
As it stands, the code also purports to support HTTPS proxies, i.e.
proxies that you connect to using SSL. These are extremely rare and
nothing is done to ensure that CONNECT requests can be made to these
as that would require multiple SSL handshakes. This use case is also
not supported by most other contemporary web tools like curl and
Firefox3.