I noticed that the exception printed in the previous commit started on the same
line as the print for the `str(e)` case right before it. Since this also prints
the content of urllib2.URLError.read(), it seems better to remove any existing
newline and re-add it, than to just assume the `str(e)` case was the only
problem.
If `ui.traceback=True` is set on the server, this prints the stacktrace for the
exception on the client side. Otherwise, nothing happens. I tried allowing the
exception to propagate back to Mercurial, but then the client sees this message
with 4.4.2 and 4.6.1:
abort: remote error:
Mercurial/Python process ends with return code 1
Something odd changed when upgrading from CentOS 7.4 to 7.5 around forwarding
requests from the loopback address that I don't fully understand. First, we
were getting a ValueError from inside `opener.open()` saying that 'localhost'
didn't match the host listed in the SSL certificate. That wasn't visible until
adding this.
Then what happened is a connection refused out of the same function, so the
traceback is added to the other handler too. Running the equivalent command on
the command line from the 'vcs' host stopped working in 7.5:
$ curl https://vcs.domain.com/hook/hg/?ping=true
curl: (7) Failed connect to vcs.domain.com:443; Connection refused
But it works when run on another machine targeting that same 'vcs' host. Adding
another firewall rule allows everything to work from the 'vcs' host again:
$ iptables -t nat -I OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 8443
The HgPermissionFilter will now inspect the used mercurial command, of all requests which are using a read method like GET, HEAD, OPTIONS or TRACE and tread every one as write request, expect:
- no command was specified with the request (this is required for the hgweb ui)
- the command in the query string was found in the list of read commands
- if query string contains the batch command, then all commands specified in X-HgArg headers must be in the list of read commands
This change is required, in order to fix CVE-2018-1000132 for SCM-Manager.
The new ExtensionPoint was introduced to remove the tight coupling between the DefaultRepositoryManager and the GitRepositoryHandler.
Git has now its own RepositoryPathMatcher which allow the matching of repository with .git or without .git extension.
