]> git.ipfire.org Git - thirdparty/git.git/commit - usage.c
vreport: sanitize ASCII control chars
authorJeff King <peff@peff.net>
Wed, 11 Jan 2017 14:02:23 +0000 (09:02 -0500)
committerJunio C Hamano <gitster@pobox.com>
Wed, 11 Jan 2017 21:54:08 +0000 (13:54 -0800)
commitf290089879501a855df2eb41db5b38cb0035a765
tree1b0f25cf5f1af2306e8d1ce374e347f5251391ff
parentb5a9e435c6dfb40df0a27521c1c6590c8f68ffb2
vreport: sanitize ASCII control chars

Our error() and die() calls may report messages with
arbitrary data (e.g., filenames or even data from a remote
server). Let's make it harder to cause confusion with
mischievous filenames. E.g., try:

  git rev-parse "$(printf "\rfatal: this argument is too sneaky")" --

or

  git rev-parse "$(printf "\x1b[5mblinky\x1b[0m")" --

Let's block all ASCII control characters, with the exception
of TAB and LF. We use both in our own messages (and we are
necessarily sanitizing the complete output of snprintf here,
as we do not have access to the individual varargs). And TAB
and LF are unlikely to cause confusion (you could put
"\nfatal: sneaky\n" in your filename, but it would at least
not _cover up_ the message leading to it, unlike "\r").

We'll replace the characters with a "?", which is similar to
how "ls" behaves. It might be nice to do something less
lossy, like converting them to "\x" hex codes. But replacing
with a single character makes it easy to do in-place and
without worrying about length limitations. This feature
should kick in rarely enough that the "?" marks are almost
never seen.

We'll leave high-bit characters as-is, as they are likely to
be UTF-8 (though there may be some Unicode mischief you
could cause, which may require further patches).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
usage.c