user/sven/git.git/shell.c, branch v2.26.0-rc2

shell: use skip_prefix() instead of starts_with()

2019-11-27T02:18:24Z

Get rid of a magic number by using skip_prefix() instead of starts_with(). Signed-off-by: René Scharfe Acked-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'nd/command-list'

2018-06-01T06:06:37Z

The list of commands with their various attributes were spread across a few places in the build procedure, but it now is getting a bit more consolidated to allow more automation. * nd/command-list: completion: allow to customize the completable command list completion: add and use --list-cmds=alias completion: add and use --list-cmds=nohelpers Move declaration for alias.c to alias.h completion: reduce completable command list completion: let git provide the completable command list command-list.txt: documentation and guide line help: use command-list.txt for the source of guides help: add "-a --verbose" to list all commands with synopsis git: support --list-cmds=list- completion: implement and use --list-cmds=main,others git --list-cmds: collect command list in a string_list git.c: convert --list-* to --list-cmds=* Remove common-cmds.h help: use command-list.h for common command list generate-cmds.sh: export all commands to command-list.h generate-cmds.sh: factor out synopsis extract code

Move declaration for alias.c to alias.h

2018-05-21T04:23:14Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

exec_cmd: rename to use dash in file name

2018-04-11T09:11:00Z

This is more consistent with the project style. The majority of Git's source files use dashes in preference to underscores in their file names. Signed-off-by: Stefan Beller

shell: drop git-cvsserver support by default

2017-09-12T02:05:58Z

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

Merge branch 'maint-2.8' into maint-2.9

2017-05-05T04:13:48Z

Merge branch 'maint-2.7' into maint-2.8

2017-05-05T04:05:03Z

shell: disallow repo names beginning with dash

2017-05-05T03:07:27Z

When a remote server uses git-shell, the client side will connect to it like: ssh server "git-upload-pack 'foo.git'" and we literally exec ("git-upload-pack", "foo.git"). In early versions of upload-pack and receive-pack, we took a repository argument and nothing else. But over time they learned to accept dashed options. If the user passes a repository name that starts with a dash, the results are confusing at best (we complain of a bogus option instead of a non-existent repository) and malicious at worst (the user can start an interactive pager via "--help"). We could pass "--" to the sub-process to make sure the user's argument is interpreted as a branch name. I.e.: git-upload-pack -- -foo.git But adding "--" automatically would make us inconsistent with a normal shell (i.e., when git-shell is not in use), where "-foo.git" would still be an error. For that case, the client would have to specify the "--", but they can't do so reliably, as existing versions of git-shell do not allow more than a single argument. The simplest thing is to simply disallow "-" at the start of the repo name argument. This hasn't worked either with or without git-shell since version 1.0.0, and nobody has complained. Note that this patch just applies to do_generic_cmd(), which runs upload-pack, receive-pack, and upload-archive. There are two other types of commands that git-shell runs: - do_cvs_cmd(), but this already restricts the argument to be the literal string "server" - admin-provided commands in the git-shell-commands directory. We'll pass along arbitrary arguments there, so these commands could have similar problems. But these commands might actually understand dashed arguments, so we cannot just block them here. It's up to the writer of the commands to make sure they are safe. With great power comes great responsibility. Reported-by: Timo Schmid Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

common-main: call git_setup_gettext()

2016-07-01T22:09:10Z

This should be part of every program, as otherwise users do not get translated error messages. However, some external commands forgot to do so (e.g., git-credential-store). This fixes them, and eliminates the repeated code in programs that did remember to use it. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

common-main: call sanitize_stdfds()

2016-07-01T22:09:10Z

This is setup that should be done in every program for safety, but we never got around to adding it everywhere (so builtins benefited from the call in git.c, but any external commands did not). Putting it in the common main() gives us this safety everywhere. Note that the case in daemon.c is a little funny. We wait until we know whether we want to daemonize, and then either: - call daemonize(), which will close stdio and reopen it to /dev/null under the hood - sanitize_stdfds(), to fix up any odd cases But that is way too late; the point of sanitizing is to give us reliable descriptors on 0/1/2, and we will already have executed code, possibly called die(), etc. The sanitizing should be the very first thing that happens. With this patch, git-daemon will sanitize first, and can remove the call in the non-daemonize case. It does mean that daemonize() may just end up closing the descriptors we opened, but that's not a big deal (it's not wrong to do so, nor is it really less optimal than the case where our parent process redirected us from /dev/null ahead of time). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano