summaryrefslogtreecommitdiff
path: root/t/lib-httpd
diff options
context:
space:
mode:
authorBlake Burkhart <bburky@bburky.com>2015-09-22 22:06:04 (GMT)
committerJunio C Hamano <gitster@pobox.com>2015-09-25 22:30:39 (GMT)
commitf4113cac0c88b4f36ee6f3abf3218034440a68e3 (patch)
tree9313f333ee5a410dbfb79de55be5f2c0433d61a7 /t/lib-httpd
parent5088d3b38775f8ac12d7f77636775b16059b67ef (diff)
downloadgit-f4113cac0c88b4f36ee6f3abf3218034440a68e3.zip
git-f4113cac0c88b4f36ee6f3abf3218034440a68e3.tar.gz
git-f4113cac0c88b4f36ee6f3abf3218034440a68e3.tar.bz2
http: limit redirection to protocol-whitelist
Previously, libcurl would follow redirection to any protocol it was compiled for support with. This is desirable to allow redirection from HTTP to HTTPS. However, it would even successfully allow redirection from HTTP to SFTP, a protocol that git does not otherwise support at all. Furthermore git's new protocol-whitelisting could be bypassed by following a redirect within the remote helper, as it was only enforced at transport selection time. This patch limits redirects within libcurl to HTTP, HTTPS, FTP and FTPS. If there is a protocol-whitelist present, this list is limited to those also allowed by the whitelist. As redirection happens from within libcurl, it is impossible for an HTTP redirect to a protocol implemented within another remote helper. When the curl version git was compiled with is too old to support restrictions on protocol redirection, we warn the user if GIT_ALLOW_PROTOCOL restrictions were requested. This is a little inaccurate, as even without that variable in the environment, we would still restrict SFTP, etc, and we do not warn in that case. But anything else means we would literally warn every time git accesses an http remote. This commit includes a test, but it is not as robust as we would hope. It redirects an http request to ftp, and checks that curl complained about the protocol, which means that we are relying on curl's specific error message to know what happened. Ideally we would redirect to a working ftp server and confirm that we can clone without protocol restrictions, and not with them. But we do not have a portable way of providing an ftp server, nor any other protocol that curl supports (https is the closest, but we would have to deal with certificates). [jk: added test and version warning] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/lib-httpd')
-rw-r--r--t/lib-httpd/apache.conf1
1 files changed, 1 insertions, 0 deletions
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index 0b81a00..68ef8ad 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -119,6 +119,7 @@ RewriteRule ^/smart-redir-perm/(.*)$ /smart/$1 [R=301]
RewriteRule ^/smart-redir-temp/(.*)$ /smart/$1 [R=302]
RewriteRule ^/smart-redir-auth/(.*)$ /auth/smart/$1 [R=301]
RewriteRule ^/smart-redir-limited/(.*)/info/refs$ /smart/$1/info/refs [R=301]
+RewriteRule ^/ftp-redir/(.*)$ ftp://localhost:1000/$1 [R=302]
<IfDefine SSL>
LoadModule ssl_module modules/mod_ssl.so