4 ms·
I suspect that the only way to effectively mitigate this is in the terminal application, by displaying a confirmation with the pasted text before accepting any
by joliss 14y ago
I suspect that the only way to effectively mitigate this is in the terminal application, by displaying a confirmation with the pasted text before accepting any multi-line[1] paste. For example here: https://code.google.com/p/iterm2/issues/detail?id=594 https://code.google.com/p/iterm2/issues/detail?id=594
[1] There may be other dangerous characters besides newlines, e.g. escape sequences. I'm not sure if it's possible to make an exhaustive list for something like Bash. Perhaps one has to guard against any paste?
- TheJH_ 14y agoThat sounds like a really good approach.
- jakub_g 14y agoIt's still possible to circumvent this by creating a one-liner using semicolons. Just grab a code like [2] and append `; rm -rf` to the selection. If the original selection was a one-liner, it'll still be. [2] http://stackoverflow.com/a/4777746/ http://stackoverflow.com/a/4777746/
- joliss 14y agoMy idea was that if you're pasting a single line, then at least you can review the command you pasted before hitting enter.
- jakub_g 14y agoI've just realized that you meant the fact that multiline pastes are often immediately executed, right? I've tried various ways of input to my console (MINGW/WinXP) for multiline pastes, and the results are as follows: 1. Right-click multiline paste: unsafe (executes immediately) 2. Windows paste (alt-space, e, p): unsafe (executes immediately) 3. Insert or Shift-Insert: safe (pastes only the first line)