[PATCH 0/2] sanitizing error message contents

When adding a warning() call in 50d341374 (http: make redirects more obvious, 2016-12-06), somebody brought up that evil servers can redirect you to something like:

  https://evil.example.com/some/repo?unused=\rwarning:+rainbows+and_unicorns_ahead

(where "\r" is a literal CR), and instead of seeing:

  warning: redirecting to https://evil.example.com/...

you just get:

  warning: rainbows and unicorns ahead

or whatever innocuous looking line they prefer (probably just ANSI "clear to beginning of line" would be even more effective).

Since it's hard to figure out which error messages could potentially contain malicious contents, and since spewing control characters to the terminal is generally bad anyway, this series sanitizes at the lowest level.

Note that this doesn't cover "remote:" lines coming over the sideband. Those are already covered for "\r", as we have to parse it to handle printing "remote:" consistently. But you can play tricks like putting:

  printf '\0331K\033[0Efatal: this looks local\n'

into a pre-receive hook. I'm not sure if we would want to do more sanitizing there. The goal of this series is not so much that a remote can't send funny strings that may look local, but that they can't prevent local strings from being displayed. OTOH, I suspect clever use of ANSI codes (moving the cursor, clearing lines, etc) could get you pretty far.

I'd be hesitant to disallow control codes entirely, though, as I suspect some servers do send colors over the sideband. So I punted on that here, but I think this is at least an incremental improvement.

  [1/2]: Revert "vreportf: avoid intermediate buffer"
  [2/2]: vreport: sanitize ASCII control chars

 usage.c | 17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

-Peff