When running `git push`, it might occur that error messages are
transferred from the server to the client. While most messages (those
explicitly sent on sideband 2) are prefixed with "remote:", it seems
that error messages printed during the automatic householding performed
by git-gc(1) are displayed without any additional decoration. Thus, such
messages can easily be misinterpreted as git-gc failing locally, see [1]
for an actual example of where that happened.
Do we want anything like the following patch (completely untested)?
-- 8< --
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index a744437..15c323a 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -1775,9 +1775,20 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
const char *argv_gc_auto[] = {
"gc", "--auto", "--quiet", NULL,
};
- int opt = RUN_GIT_CMD | RUN_COMMAND_STDOUT_TO_STDERR;
+ struct child_process proc = CHILD_PROCESS_INIT;
+
+ proc.no_stdin = 1;
+ proc.stdout_to_stderr = 1;
+ proc.err = use_sideband ? -1 : 0;
+ proc.git_cmd = 1;
+ proc.argv = argv_gc_auto;
+
close_all_packs();
- run_command_v_opt(argv_gc_auto, opt);
+ if (!start_command(&proc)) {
+ if (use_sideband)
+ copy_to_sideband(proc.err, -1, NULL);
+ finish_command(&proc);
+ }
}
if (auto_update_server_info)
update_server_info(0);
-- 8< --
More generally, do we care about making *all* "remote" strings easily
distinguishable from "local" strings? Even though it is unlikely to use
this for an actual attack, it seems that a malicious server can
currently trick a user into performing an action by printing a message
that looks like something coming from "local" Git. Prefixing every
server message by "remote:" might look a bit ugly but maybe we can
simply use a different color instead and fall back to the prefix on
terminals without color support. Opinions?
[1] https://lists.archlinux.org/pipermail/aur-general/2016-June/032340.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html