[Bug 2434] scp can send arbitrary control characters / escape sequences to the terminal

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2434

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
TL;DR signals are hard, lets go do some neurosurgery

Looking at this again, this is quite difficult to fix so long as our
progress meter runs in signal context.

Even if we got rid of the malloc calls in utf8.c, that code can never
be safe to run in a signal handler - none of the mb*/wc* standard
library functions are signal-safe.

Some alternatives:

1. Use a thread

Nope.

2. Make utf8.c signal-safe

This would mean ditching use of mb*/wc* and redoing it longhand. Not
impossible but big and brittle. Probably a non-starter.

3. Arrange for the formatting (at least of the filename) to happen in a
non-signal context

Perhaps we could do it in scpio somehow? The problem here is that it is
only called at present for complete writes from atomicio, but perhaps
we could add some heuristic that allowed it to be called when the
underlying read/write was interrupted by a signal too?

We'd still need to be careful though - we couldn't naively update the
string that gets written by the progress meter code as a SIGALRM could
come along while we're updating it.

I think we could do it by doing something like: replacing the filenames
with a short array of filenames, a sig_atomic_t index that points to
the one that is safe to write to and a way to update the index.

4. Allow safe truncation of the filename in signal context.

The main thing the progress meter code needs to do with the filename is
truncate it appropriately when it doesn't fit the terminal's columns.
The problem this presents for multibyte locales is picking the spots
where we can safely split it.

We could have start_progress_meter() record an array of "split points"
and have refresh_progress_meter() pick the one that makes the sanitised
filename fit.

This might be the easiest to do, but we'd need a new API in utf8.c

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.