summaryrefslogtreecommitdiff
path: root/t/t5802-connect-helper.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-12-15transport: add protocol policy config optionLibravatar Brandon Williams1-0/+1
Previously the `GIT_ALLOW_PROTOCOL` environment variable was used to specify a whitelist of protocols to be used in clone/fetch/push commands. This patch introduces new configuration options for more fine-grained control for allowing/disallowing protocols. This also has the added benefit of allowing easier construction of a protocol whitelist on systems where setting an environment variable is non-trivial. Now users can specify a policy to be used for each type of protocol via the 'protocol.<name>.allow' config option. A default policy for all unconfigured protocols can be set with the 'protocol.allow' config option. If no user configured default is made git will allow known-safe protocols (http, https, git, ssh, file), disallow known-dangerous protocols (ext), and have a default policy of `user` for all other protocols. The supported policies are `always`, `never`, and `user`. The `user` policy can be used to configure a protocol to be usable when explicitly used by a user, while disallowing it for commands which run clone/fetch/push commands without direct user intervention (e.g. recursive initialization of submodules). Commands which can potentially clone/fetch/push from untrusted repositories without user intervention can export `GIT_PROTOCOL_FROM_USER` with a value of '0' to prevent protocols configured to the `user` policy from being used. Fix remote-ext tests to use the new config to allow the ext protocol to be tested. Based on a patch by Jeff King <peff@peff.net> Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25remote-ext: simplify git pkt-line generationLibravatar Jeff King1-0/+28
We format a pkt-line into a heap buffer, which requires manual computation of the required size, and uses some bare sprintf calls. We could use a strbuf instead, which would take care of the computation for us. But it's even easier still to use packet_write(). Besides handling the formatting and writing for us, it fixes two things: 1. Our manual max-size check used 0xFFFF, while technically LARGE_PACKET_MAX is slightly smaller than this. 2. Our packet will now be output as part of GIT_TRACE_PACKET debugging. Unfortunately packet_write() does not let us build up the buffer progressively, so we do have to repeat ourselves a little depending on the "vhost" setting, but the end result is still far more readable than the original. Since there were no tests covering this feature at all, we'll add a few into t5802. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-07t5802: add test for connect helperLibravatar Junio C Hamano1-0/+72
This is an attempt to reproduce a problem reported for a third-party custom "connect" remote helper. The conjecture is that sometimes "git fetch" wants to make two connections (one for the primary transfer with 'follow-tags' option set, and then after noticing that some tags are not packed because the primary transfer did not have to send any commit that is pointed by them, another to explicitly ask for the missing tags), and their "connect" helper is not called in the second request, breaking the "fetch" as a whole. Unfortunately this test script does not trigger the alleged failure and happily passes when talking to upload-pack from git-core (see patch 5/5 for details). Signed-off-by: Junio C Hamano <gitster@pobox.com>