kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Jeff King	b81401c1de	http: prompt for credentials on failed POST All of the smart-http GET requests go through the http_get_* functions, which will prompt for credentials and retry if we see an HTTP 401. POST requests, however, do not go through any central point. Moreover, it is difficult to retry in the general case; we cannot assume the request body fits in memory or is even seekable, and we don't know how much of it was consumed during the attempt. Most of the time, this is not a big deal; for both fetching and pushing, we make a GET request before doing any POSTs, so typically we figure out the credentials during the first request, then reuse them during the POST. However, some servers may allow a client to get the list of refs from receive-pack without authentication, and then require authentication when the client actually tries to POST the pack. This is not ideal, as the client may do a non-trivial amount of work to generate the pack (e.g., delta-compressing objects). However, for a long time it has been the recommended example configuration in git-http-backend(1) for setting up a repository with anonymous fetch and authenticated push. This setup has always been broken without putting a username into the URL. Prior to commit `986bbc0`, it did work with a username in the URL, because git would prompt for credentials before making any requests at all. However, post-986bbc0, it is totally broken. Since it has been advertised in the manpage for some time, we should make sure it works. Unfortunately, it is not as easy as simply calling post_rpc again when it fails, due to the input issue mentioned above. However, we can still make this specific case work by retrying in two specific instances: 1. If the request is large (bigger than LARGE_PACKET_MAX), we will first send a probe request with a single flush packet. Since this request is static, we can freely retry it. 2. If the request is small and we are not using gzip, then we have the whole thing in-core, and we can freely retry. That means we will not retry in some instances, including: 1. If we are using gzip. However, we only do so when calling git-upload-pack, so it does not apply to pushes. 2. If we have a large request, the probe succeeds, but then the real POST wants authentication. This is an extremely unlikely configuration and not worth worrying about. While it might be nice to cover those instances, doing so would be significantly more complex for very little real-world gain. In the long run, we will be much better off when curl learns to internally handle authentication as a callback, and we can cleanly handle all cases that way. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jeff King	4c71009da6	t: test http access to "half-auth" repositories Some sites set up http access to repositories such that fetching is anonymous and unauthenticated, but pushing is authenticated. While there are multiple ways to do this, the technique advertised in the git-http-backend manpage is to block access to locations matching "/git-receive-pack$". Let's emulate that advice in our test setup, which makes it clear that this advice does not actually work. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jeff King	6ac2b3aeb9	t: test basic smart-http authentication We do not currently test authentication over smart-http at all. In theory, it should work exactly as it does for dumb http (which we do test). It does indeed work for these simple tests, but this patch lays the groundwork for more complex tests in future patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Matthieu Moy	f2c2c90103	push: start warning upcoming default change for push.default In preparation for flipping the default to the "simple" mode from the "matching" mode that is the historical default, start warning users when they rely on unconfigured "git push" to default to the "matching" mode. Also, advertise for 'simple' where 'current' and 'upstream' are advised. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jeff King	e304aeba20	t5541: test more combinations of --progress Previously, we tested only that "push --quiet --no-progress" was silent. However, there are many other combinations that were not tested: 1. no options at all (but stderr as a tty) 2. --no-progress by itself 3. --quiet by itself 4. --progress (when stderr not a tty) These are tested elsewhere for general "push", but it is important to test them separately for http. It follows a very different code path than git://, and options must be relayed across a remote helper to a separate send-pack process (and in fact cases (1), (2), and (4) have all been broken just for http at some point in the past). We can drop the "--quiet --no-progress" test, as it is not really interesting (it is already handled by testing them separately in (2) and (3) above). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Christopher Tiwald	0aff719f48	Fix httpd tests that broke when non-ff push advice changed Signed-off-by: Christopher Tiwald <christiwald@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jeff King	e32a4581bc	http-backend: respect existing GIT_COMMITTER_* variables The http-backend program sets default GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL variables based on the REMOTE_USER and REMOTE_ADDR variables provided by the webserver. However, it unconditionally overwrites any existing GIT_COMMITTER variables, which may have been customized by site-specific code in the webserver (or in a script wrapping http-backend). Let's leave those variables intact if they already exist, assuming that any such configuration was intentional. There is a slight chance of a regression if somebody has set GIT_COMMITTER_* for the entire webserver, not intending it to leak through http-backend. We could protect against this by passing the information in alternate variables. However, it seems unlikely that anyone will care about that regression, and there is value in the simplicity of using the common variable names that are used elsewhere in git. While we're tweaking the environment-handling in http-backend, let's switch it to use argv_array to handle the list of variables. That makes the memory management much simpler. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Clemens Buchacher	d202a513a4	t5541: check error message against the real port number used Otherwise the test cannot be run with custom port set to LIB_HTTPD_PORT. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Shawn O. Pearce	5238cbf656	remote-curl: Fix push status report when all branches fail The protocol between transport-helper.c and remote-curl requires remote-curl to always print a blank line after the push command has run. If the blank line is ommitted, transport-helper kills its container process (the git push the user started) with exit(128) and no message indicating a problem, assuming the helper already printed reasonable error text to the console. However if the remote rejects all branches with "ng" commands in the report-status reply, send-pack terminates with non-zero status, and in turn remote-curl exited with non-zero status before outputting the blank line after the helper status printed by send-pack. No error messages reach the user. This caused users to see the following from git push over HTTP when the remote side's update hook rejected the branch: $ git push http://... master Counting objects: 4, done. Delta compression using up to 6 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 301 bytes, done. Total 3 (delta 0), reused 0 (delta 0) $ Always print a blank line after the send-pack process terminates, ensuring the helper status report (if it was output) will be correctly parsed by the calling transport-helper.c. This ensures the helper doesn't abort before the status report can be shown to the user. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Michael J Gruber	d336572f57	t5541: avoid TAP test miscounting lib-terminal.sh runs a test and thus increases the test count, but the output is lost so that TAP produces a "no plan found error". Move the lib-terminal call after the lib-httpd and make TAP happy (though still leave me clueless). Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Clemens Buchacher	c207e34f77	fix push --quiet: add 'quiet' capability to receive-pack Currently, git push --quiet produces some non-error output, e.g.: $ git push --quiet Unpacking objects: 100% (3/3), done. This fixes a bug reported for the fedora git package: https://bugzilla.redhat.com/show_bug.cgi?id=725593 Reported-by: Jesse Keating <jkeating@redhat.com> Cc: Todd Zullinger <tmz@pobox.com> Commit `90a6c7d4` (propagate --quiet to send-pack/receive-pack) introduced the --quiet option to receive-pack and made send-pack pass that option. Older versions of receive-pack do not recognize the option, however, and terminate immediately. The commit was therefore reverted. This change instead adds a 'quiet' capability to receive-pack, which is a backwards compatible. In addition, this fixes push --quiet via http: A verbosity of 0 means quiet for remote helpers. Reported-by: Tobias Ulmer <tobiasu@tmux.org> Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jeff King	02f7914734	remote-curl: don't pass back fake refs When receive-pack advertises its list of refs, it generally hides the capabilities information after a NUL at the end of the first ref. However, when we have an empty repository, there are no refs, and therefore receive-pack writes a fake ref "capabilities^{}" with the capabilities afterwards. On the client side, git reads the result with get_remote_heads(). We pick the capabilities from the end of the line, and then call check_ref() to make sure the ref name is valid. We see that it isn't, and don't bother adding it to our list of refs. However, the call to check_ref() is enabled by passing the REF_NORMAL flag to get_remote_heads. For the regular git transport, we pass REF_NORMAL in get_refs_via_connect() if we are doing a push (since only receive-pack uses this fake ref). But in remote-curl, we never use this flag, and we accept the fake ref as a real one, passing it back from the helper to the parent git-push. Most of the time this bug goes unnoticed, as the fake ref won't match our refspecs. However, if "--mirror" is used, then we see it as remote cruft to be pruned, and try to pass along a deletion refspec for it. Of course this refspec has bogus syntax (because of the ^{}), and the helper complains, aborting the push. Let's have remote-curl mirror what the builtin get_refs_via_connect() does (at least for the case of using git protocol; we can leave the dumb info/refs reader as it is). This also fixes pushing with --mirror to a smart-http remote that uses alternates. The fake ".have" refs the server gives to avoid unnecessary network transfer has a similar bad interactions with the machinery. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Tay Ray Chuan	0cc6330d0c	t5541-http-push: add test for chunked Trigger the chunked type of pushing for smart HTTP. This can serve as a regression test for the issue fixed in `1e41827` (http: clear POSTFIELDS when initializing a slot). Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Junio C Hamano	b3e1900a74	i18n: use test_i18ncmp and test_i18ngrep in t5541, t6040, t6120, t7004, t7012 and t7060 Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Ævar Arnfjörð Bjarmason	b32227e770	i18n: git-push "prevent you from losing" message Gettextize the "To prevent you from losing history" message. A test in lib-httpd.sh and another in t5541-http-push.sh explicitly checked for this message. Change them to skip under GETTEXT_POISON=YesPlease. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Brandon Casey	77b5be2aba	t/{t5541,lib-httpd}: replace problematic '!()' notation with test_must_fail The '!()' notation is interpreted as a pattern-list on Ksh. The Ksh man page describe it as follows: !(pattern-list) Matches anything except one of the given patterns. Ksh performs a file glob using the pattern-list and then tries to execute the first file in the list. If a space is added between the '!' and the open parens, then Ksh will not interpret it as a pattern list, but in this case, it is preferred to use test_must_fail, so lets do so. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Ævar Arnfjörð Bjarmason	fadb5156e4	tests: Skip tests in a way that makes sense under TAP SKIP messages are now part of the TAP plan. A TAP harness now knows why a particular test was skipped and can report that information. The non-TAP harness built into Git's test-lib did nothing special with these messages, and is unaffected by these changes. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tay Ray Chuan	d8fab07208	remote-curl: ensure that URLs have a trailing slash Previously, we blindly assumed that URLs passed to the remote-curl helper did not end with a trailing slash. Use the convenience function end_url_with_slash() from http.[ch] to ensure that URLs have a trailing slash on invocation of the remote-curl helper, and use the URL as one with a trailing slash throughout. It is possible for users to pass a URL with a trailing slash to remote-curl, by, say, setting it in remote.<name>.url in their git config. The resulting requests have an empty path component (//) and may break implementations of the http git protocol. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tay Ray Chuan	9ee6bcd398	t5541-http-push: add test for URLs with trailing slash Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tay Ray Chuan	6cbd6e9261	t554[01]-http-push: refactor, add non-ff tests Move non-fast forward tests to lib-httpd.sh so that we don't have to duplicate the tests in both t5540 and t5541. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tay Ray Chuan	fe4bc2a5ae	t5541-http-push: check that ref is unchanged for non-ff test Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tay Ray Chuan	9567f082dd	t5541-http-push: make grep expression check for one line only Don't feed a multiple-line pattern to grep and expect the them to match with lines in order. Simplify the grep expressions in the non-fast-forward tests to check only for the first line of the non-fast-forward warning - having that line should be enough assurance that the full warning is printed. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tay Ray Chuan	08d63a422b	transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed If the status of a ref is REF_STATUS_NONE, the remote helper will not be told to push the ref (via a 'push' command). However, the remote helper may still act on these refs. If the helper does act on the ref, and prints a status for it, ignore the report (ie. don't overwrite the status of the ref with it, nor the message in the remote_status member) if the reported status is 'no match'. This allows the user to be alerted to more "interesting" ref statuses, like REF_STATUS_NONFASTFORWARD. Cc: Jeff King <peff@peff.net> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tay Ray Chuan	4232826771	transport.c::transport_push(): make ref status affect return value Use push_had_errors() to check the refs for errors and modify the return value. Mark the non-fast-forward push tests to succeed. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tay Ray Chuan	20e8b465a5	refactor ref status logic for pushing Move the logic that detects up-to-date and non-fast-forward refs to a new function in remote.[ch], set_ref_status_for_push(). Make transport_push() invoke set_ref_status_for_push() before invoking the push_refs() implementation. (As a side-effect, the push_refs() implementation in transport-helper.c now knows of non-fast-forward pushes.) Removed logic for detecting up-to-date refs from the push_refs() implementation in transport-helper.c, as transport_push() has already done so for it. Make cmd_send_pack() invoke set_ref_status_for_push() before invoking send_pack(), as transport_push() can't do it for send_pack() here. Mark the test on the return status of non-fast-forward push to fail. Git now exits with success, as transport.c::transport_push() does not check for refs with status REF_STATUS_REJECT_NONFASTFORWARD nor does it indicate rejected pushes with its return value. Mark the test for ref status to succeed. As mentioned earlier, refs might be marked as non-fast-forwards, triggering the push status printing mechanism in transport.c. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tay Ray Chuan	7b69079be9	t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs Some refs can only be matched to a remote ref with an explicit refspec. When such a ref is a non-fast-forward of its remote ref, test that pushing them (with the explicit refspec specified) fails with a non- fast-foward-type error (viz. printing of ref status and help message). Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Tay Ray Chuan	1945237486	t5541-http-push.sh: add tests for non-fast-forward pushes Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Shawn O. Pearce	7da4e2280c	test smart http fetch and push The top level directory "/smart/" of the test Apache server is mapped through our git-http-backend CGI, but uses the same underlying repository space as the server's document root. This is the most simple installation possible. Server logs are checked to verify the client has accessed only the smart URLs during the test. During fetch testing the headers are also logged from libcurl to ensure we are making a reasonably sane HTTP request, and getting back reasonably sane response headers from the CGI. When validating the request headers used during smart fetch we munge away the actual Content-Length and replace it with the placeholder "xxx". This avoids unnecessary varability in the test caused by an unrelated change in the requested capabilities in the first want line of the request. However, we still want to look for and verify that Content-Length was used, because smaller payloads should be using Content-Length and not "Transfer-Encoding: chunked". When validating the server response headers we must discard both Content-Length and Transfer-Encoding, as Apache2 can use either format to return our response. During development of this test I observed Apache returning both forms, depending on when the processes got CPU time. If our CGI returned the pack data quickly, Apache just buffered the whole thing and returned a Content-Length. If our CGI took just a bit too long to complete, Apache flushed its buffer and instead used "Transfer-Encoding: chunked". Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago

41 Commits (71c7b0538f8f037e49a04f415a6fbf0bba2c85ad)