summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-01-09bisect: debug: convert struct object to object_idLibravatar Yasushi SHOJI1-3/+3
The commit f2fd0760 ("Convert struct object to object_id", 2015-11-10) converted struct object to object_id but forgot to adjust a few callers in a debug function show_list(), which is ifdef'ed to noop, in bisect.c. Signed-off-by: Yasushi SHOJI <Yasushi.SHOJI@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22Git 2.12.5Libravatar Junio C Hamano3-2/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22Sync with 2.11.4Libravatar Junio C Hamano8-56/+138
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22Git 2.11.4Libravatar Junio C Hamano3-2/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22Sync with 2.10.5Libravatar Junio C Hamano7-56/+121
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22Git 2.10.5Libravatar Junio C Hamano3-2/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22Merge branch 'jk/safe-pipe-capture' into maint-2.10Libravatar Junio C Hamano1-2/+2
2017-09-22Merge branch 'jk/cvsimport-quoting' into maint-2.10Libravatar Junio C Hamano1-0/+1
2017-09-22Merge branch 'jc/cvsserver' into maint-2.10Libravatar Junio C Hamano1-40/+37
2017-09-22Merge branch 'jk/git-shell-drop-cvsserver' into maint-2.10Libravatar Junio C Hamano3-14/+64
2017-09-12cvsimport: shell-quote variable used in backticksLibravatar Jeff King1-0/+1
We run `git rev-parse` though the shell, and quote its argument only with single-quotes. This prevents most metacharacters from being a problem, but misses the obvious case when $name itself has single-quotes in it. We can fix this by applying the usual shell-quoting formula. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-12archimport: use safe_pipe_capture for user inputLibravatar Jeff King1-2/+2
Refnames can contain shell metacharacters which need to be passed verbatim to sub-processes. Using safe_pipe_capture skips the shell entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-12shell: drop git-cvsserver support by defaultLibravatar Jeff King3-14/+64
The git-cvsserver script is old and largely unmaintained these days. But git-shell allows untrusted users to run it out of the box, significantly increasing its attack surface. Let's drop it from git-shell's list of internal handlers so that it cannot be run by default. This is not backwards compatible. But given the age and development activity on CVS-related parts of Git, this is likely to impact very few users, while helping many more (i.e., anybody who runs git-shell and had no intention of supporting CVS). There's no configuration mechanism in git-shell for us to add a boolean and flip it to "off". But there is a mechanism for adding custom commands, and adding CVS support here is fairly trivial. Let's document it to give guidance to anybody who really is still running cvsserver. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-11cvsserver: use safe_pipe_capture for `constant commands` as wellLibravatar Junio C Hamano1-4/+4
This is not strictly necessary, but it is a good code hygiene. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-11cvsserver: use safe_pipe_capture instead of backticksLibravatar joernchen1-11/+11
This makes the script pass arguments that are derived from end-user input in safer way when invoking subcommands. Reported-by: joernchen <joernchen@phenoelit.de> Signed-off-by: joernchen <joernchen@phenoelit.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-11cvsserver: move safe_pipe_capture() to the main packageLibravatar Junio C Hamano1-25/+22
As a preparation for replacing `command` with a call to this function from outside GITCVS::updater package, move it to the main package. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-30Git 2.12.4Libravatar Junio C Hamano3-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-30Merge tag 'v2.11.3' into maint-2.12Libravatar Junio C Hamano11-0/+116
Git 2.11.3
2017-07-30Merge branch 'jk/lib-proto-disable-cleanup' into maint-2.12Libravatar Junio C Hamano1-2/+6
2017-07-30Git 2.11.3Libravatar Junio C Hamano3-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-30Merge tag 'v2.10.4' into maint-2.11Libravatar Junio C Hamano10-0/+112
Git 2.10.4
2017-07-30Git 2.10.4Libravatar Junio C Hamano3-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-30Merge tag 'v2.9.5' into maint-2.10Libravatar Junio C Hamano9-0/+108
Git 2.9.5
2017-07-30Git 2.9.5Libravatar Junio C Hamano3-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-30Merge tag 'v2.8.6' into maint-2.9Libravatar Junio C Hamano8-0/+104
Git 2.8.6
2017-07-30Git 2.8.6Libravatar Junio C Hamano3-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-30Merge tag 'v2.7.6' into maint-2.8Libravatar Junio C Hamano7-0/+100
Git 2.7.6
2017-07-30Git 2.7.6Libravatar Junio C Hamano3-2/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28Merge branch 'jk/ssh-funny-url' into maint-2.7Libravatar Junio C Hamano6-0/+75
2017-07-28connect: reject paths that look like command line optionsLibravatar Jeff King3-0/+40
If we get a repo path like "-repo.git", we may try to invoke "git-upload-pack -repo.git". This is going to fail, since upload-pack will interpret it as a set of bogus options. But let's reject this before we even run the sub-program, since we would not want to allow any mischief with repo names that actually are real command-line options. You can still ask for such a path via git-daemon, but there's no security problem there, because git-daemon enters the repo itself and then passes "." on the command line. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28connect: reject dashed arguments for proxy commandsLibravatar Jeff King2-0/+10
If you have a GIT_PROXY_COMMAND configured, we will run it with the host/port on the command-line. If a URL contains a mischievous host like "--foo", we don't know how the proxy command may handle it. It's likely to break, but it may also do something dangerous and unwanted (technically it could even do something useful, but that seems unlikely). We should err on the side of caution and reject this before we even run the command. The hostname check matches the one we do in a similar circumstance for ssh. The port check is not present for ssh, but there it's not necessary because the syntax is "-p <port>", and there's no ambiguity on the parsing side. It's not clear whether you can actually get a negative port to the proxy here or not. Doing: git fetch git://remote:-1234/repo.git keeps the "-1234" as part of the hostname, with the default port of 9418. But it's a good idea to keep this check close to the point of running the command to make it clear that there's no way to circumvent it (and at worst it serves as a belt-and-suspenders check). Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28connect: factor out "looks like command line option" checkLibravatar Jeff King3-1/+14
We reject hostnames that start with a dash because they may be confused for command-line options. Let's factor out that notion into a helper function, as we'll use it in more places. And while it's simple now, it's not clear if some systems might need more complex logic to handle all cases. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28t5813: add test for hostname starting with dashLibravatar Jeff King1-0/+9
Per the explanation in the previous patch, this should be (and is) rejected. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28connect: reject ssh hostname that begins with a dashLibravatar Junio C Hamano1-0/+3
When commands like "git fetch" talk with ssh://$rest_of_URL/, the code splits $rest_of_URL into components like host, port, etc., and then spawns the underlying "ssh" program by formulating argv[] array that has: - the path to ssh command taken from GIT_SSH_COMMAND, etc. - dashed options like '-batch' (for Tortoise), '-p <port>' as needed. - ssh_host, which is supposed to be the hostname parsed out of $rest_of_URL. - then the command to be run on the other side, e.g. git upload-pack. If the ssh_host ends up getting '-<anything>', the argv[] that is used to spawn the command becomes something like: { "ssh", "-p", "22", "-<anything>", "command", "to", "run", NULL } which obviously is bogus, but depending on the actual value of "<anything>", will make "ssh" parse and use it as an option. Prevent this by forbidding ssh_host that begins with a "-". Noticed-by: Joern Schneeweisz of Recurity Labs Reported-by: Brian at GitLab Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28t/lib-proto-disable: restore protocol.allow after config testsLibravatar Jeff King1-2/+6
The tests for protocol.allow actually set that variable in the on-disk config, run a series of tests, and then never clean up after themselves. This means that whatever tests we run after have protocol.allow=never, which may influence their results. In most cases we either exit after running these tests, or do another round of test_proto(). In the latter case, this happens to work because: 1. Tests of the GIT_ALLOW_PROTOCOL environment variable override the config. 2. Tests of the specific config "protocol.foo.allow" override the protocol.allow config. 3. The next round of protocol.allow tests start off by setting the config to a known value. However, it's a land-mine waiting to trap somebody adding new tests to one of the t581x test scripts. Let's make sure we clean up after ourselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Git 2.12.3Libravatar Junio C Hamano3-4/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.11' into maintLibravatar Junio C Hamano10-8/+105
2017-05-05Git 2.11.2Libravatar Junio C Hamano4-3/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.10' into maint-2.11Libravatar Junio C Hamano9-8/+92
2017-05-05Git 2.10.3Libravatar Junio C Hamano3-2/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.9' into maint-2.10Libravatar Junio C Hamano8-7/+83
2017-05-05Git 2.9.4Libravatar Junio C Hamano3-2/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.8' into maint-2.9Libravatar Junio C Hamano7-6/+74
2017-05-05Git 2.8.5Libravatar Junio C Hamano4-3/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.7' into maint-2.8Libravatar Junio C Hamano6-5/+60
2017-05-05Git 2.7.5Libravatar Junio C Hamano4-3/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.6' into maint-2.7Libravatar Junio C Hamano5-4/+43
2017-05-05Git 2.6.7Libravatar Junio C Hamano4-3/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.5' into maint-2.6Libravatar Junio C Hamano4-3/+29
2017-05-05Git 2.5.6Libravatar Junio C Hamano4-3/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>