git/http.c, branch v2.3.10

http: limit redirection depth

2015-09-25T22:32:28Z

By default, libcurl will follow circular http redirects forever. Let's put a cap on this so that somebody who can trigger an automated fetch of an arbitrary repository (e.g., for CI) cannot convince git to loop infinitely. The value chosen is 20, which is the same default that Firefox uses. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

http: limit redirection to protocol-whitelist

2015-09-25T22:30:39Z

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 Signed-off-by: Junio C Hamano

Merge branch 'jk/dumb-http-idx-fetch-fix' into maint

2015-02-25T06:10:37Z

A broken pack .idx file in the receiving repository prevented the dumb http transport from fetching a good copy of it from the other side. * jk/dumb-http-idx-fetch-fix: dumb-http: do not pass NULL path to parse_pack_index

dumb-http: do not pass NULL path to parse_pack_index

2015-01-27T20:41:45Z

Once upon a time, dumb http always fetched .idx files directly into their final location, and then checked their validity with parse_pack_index. This was refactored in commit 750ef42 (http-fetch: Use temporary files for pack-*.idx until verified, 2010-04-19), which uses the following logic: 1. If we have the idx already in place, see if it's valid (using parse_pack_index). If so, use it. 2. Otherwise, fetch the .idx to a tempfile, check that, and if so move it into place. 3. Either way, fetch the pack itself if necessary. However, it got step 1 wrong. We pass a NULL path parameter to parse_pack_index, so an existing .idx file always looks broken. Worse, we do not treat this broken .idx as an opportunity to re-fetch, but instead return an error, ignoring the pack entirely. This can lead to a dumb-http fetch failing to retrieve the necessary objects. This doesn't come up much in practice, because it must be a packfile that we found out about (and whose .idx we stored) during an earlier dumb-http fetch, but whose packfile we _didn't_ fetch. I.e., we did a partial clone of a repository, didn't need some packfiles, and now a followup fetch needs them. Discovery and tests by Charles Bailey . Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

remote-curl: fall back to Basic auth if Negotiate fails

2015-01-08T03:48:19Z

Apache servers using mod_auth_kerb can be configured to allow the user to authenticate either using Negotiate (using the Kerberos ticket) or Basic authentication (using the Kerberos password). Often, one will want to use Negotiate authentication if it is available, but fall back to Basic authentication if the ticket is missing or expired. However, libcurl will try very hard to use something other than Basic auth, even over HTTPS. If Basic and something else are offered, libcurl will never attempt to use Basic, even if the other option fails. Teach the HTTP client code to stop trying authentication mechanisms that don't use a password (currently Negotiate) after the first failure, since if they failed the first time, they will never succeed. Signed-off-by: brian m. carlson Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'da/include-compat-util-first-in-c'

2014-10-14T17:49:01Z

Code clean-up. * da/include-compat-util-first-in-c: cleanups: ensure that git-compat-util.h is included first

cleanups: ensure that git-compat-util.h is included first

2014-09-15T19:05:14Z

CodingGuidelines states that the first #include in C files should be git-compat-util.h or another header file that includes it, such as cache.h or builtin.h. Signed-off-by: David Aguilar Signed-off-by: Junio C Hamano

Merge branch 'br/http-init-fix'

2014-09-11T17:33:28Z

Code clean-up. * br/http-init-fix: http: style fixes for curl_multi_init error check http.c: die if curl_*_init fails

http: style fixes for curl_multi_init error check

2014-08-21T17:53:55Z

Unless there is a good reason, we should use die() rather than fprintf/exit. We can also shorten the message to match other curl init failures (and match our usual lowercase no-full-stop style). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

run-command: introduce CHILD_PROCESS_INIT

2014-08-20T16:53:37Z

Most struct child_process variables are cleared using memset first after declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to initialize them statically instead. That's shorter, doesn't require a function call and is slightly more readable (especially given that we already have STRBUF_INIT, ARGV_ARRAY_INIT etc.). Helped-by: Johannes Sixt Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano