git/daemon.c, branch v2.12.2

Merge branch 'ls/filter-process'

2016-10-31T20:15:21Z

The smudge/clean filter API expect an external process is spawned to filter the contents for each path that has a filter defined. A new type of "process" filter API has been added to allow the first request to run the filter for a path to spawn a single process, and all filtering need is served by this single process for multiple paths, reducing the process creation overhead. * ls/filter-process: contrib/long-running-filter: add long running filter example convert: add filter..process option convert: prepare filter..process option convert: make apply_filter() adhere to standard Git error handling pkt-line: add functions to read/write flush terminated packet streams pkt-line: add packet_write_gently() pkt-line: add packet_flush_gently() pkt-line: add packet_write_fmt_gently() pkt-line: extract set_packet_header() pkt-line: rename packet_write() to packet_write_fmt() run-command: add clean_on_exit_handler run-command: move check_pipe() from write_or_die to run_command convert: modernize tests convert: quote filter names in error messages

Merge branch 'jk/daemon-path-ok-check-truncation'

2016-10-27T21:58:50Z

"git daemon" used fixed-length buffers to turn URL to the repository the client asked for into the server side directory path, using snprintf() to avoid overflowing these buffers, but allowed possibly truncated paths to the directory. This has been tightened to reject such a request that causes overlong path to be required to serve. * jk/daemon-path-ok-check-truncation: daemon: detect and reject too-long paths

daemon: detect and reject too-long paths

2016-10-24T16:59:29Z

When we are checking the path via path_ok(), we use some fixed PATH_MAX buffers. We write into them via snprintf(), so there's no possibility of overflow, but it does mean we may silently truncate the path, leading to potentially confusing errors when the partial path does not exist. We're better off to reject the path explicitly. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

pkt-line: rename packet_write() to packet_write_fmt()

2016-10-17T18:36:50Z

packet_write() should be called packet_write_fmt() because it is a printf-like function that takes a format string as first parameter. packet_write_fmt() should be used for text strings only. Arbitrary binary data should use a new packet_write() function that is introduced in a subsequent patch. Suggested-by: Junio C Hamano Signed-off-by: Lars Schneider Signed-off-by: Junio C Hamano

Merge branch 'ew/daemon-socket-keepalive'

2016-07-28T17:34:43Z

Recent update to "git daemon" tries to enable the socket-level KEEPALIVE, but when it is spawned via inetd, the standard input file descriptor may not necessarily be connected to a socket. Suppress an ENOTSOCK error from setsockopt(). * ew/daemon-socket-keepalive: Windows: add missing definition of ENOTSOCK daemon: ignore ENOTSOCK from setsockopt

Merge branch 'jk/common-main'

2016-07-19T20:22:19Z

There are certain house-keeping tasks that need to be performed at the very beginning of any Git program, and programs that are not built-in commands had to do them exactly the same way as "git" potty does. It was easy to make mistakes in one-off standalone programs (like test helpers). A common "main()" function that calls cmd_main() of individual program has been introduced to make it harder to make mistakes. * jk/common-main: mingw: declare main()'s argv as const common-main: call git_setup_gettext() common-main: call restore_sigpipe_to_default() common-main: call sanitize_stdfds() common-main: call git_extract_argv0_path() add an extra level of indirection to main()

daemon: ignore ENOTSOCK from setsockopt

2016-07-18T18:09:52Z

In inetd mode, we are not guaranteed stdin or stdout is a socket; callers could filter the data through a pipe or be testing with regular files. This prevents t5802 from polluting syslog. Signed-off-by: Eric Wong 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

common-main: call git_extract_argv0_path()

2016-07-01T22:09:10Z

Every program which links against libgit.a must call this function, or risk hitting an assert() in system_path() that checks whether we have configured argv0_path (though only when RUNTIME_PREFIX is defined, so essentially only on Windows). Looking at the diff, you can see that putting it into the common main() saves us having to do it individually in each of the external commands. But what you can't see are the cases where we _should_ have been doing so, but weren't (e.g., git-credential-store, and all of the t/helper test programs). This has been an accident-waiting-to-happen for a long time, but wasn't triggered until recently because it involves one of those programs actually calling system_path(). That happened with git-credential-store in v2.8.0 with ae5f677 (lazily load core.sharedrepository, 2016-03-11). The program: - takes a lock file, which... - opens a tempfile, which... - calls adjust_shared_perm to fix permissions, which... - lazy-loads the config (as of ae5f677), which... - calls system_path() to find the location of /etc/gitconfig On systems with RUNTIME_PREFIX, this means credential-store reliably hits that assert() and cannot be used. We never noticed in the test suite, because we set GIT_CONFIG_NOSYSTEM there, which skips the system_path() lookup entirely. But if we were to tweak git_config() to find /etc/gitconfig even when we aren't going to open it, then the test suite shows multiple failures (for credential-store, and for some other test helpers). I didn't include that tweak here because it's way too specific to this particular call to be worth carrying around what is essentially dead code. The implementation is fairly straightforward, with one exception: there is exactly one caller (git.c) that actually cares about the result of the function, and not the side-effect of setting up argv0_path. We can accommodate that by simply replacing the value of argv[0] in the array we hand down to cmd_main(). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano