5 ms·
Serious question: is xterm really entirely at fault here? Doesn't zsh get some of the blame? > It so happens ^G is in Zsh when in vi line editing mode bound to
by classichasclass 4y ago
Serious question: is xterm really entirely at fault here? Doesn't zsh get some of the blame?
> It so happens ^G is in Zsh when in vi line editing mode bound to "list-expand". Which can run commands as part of the expansion leading to command execution without pressing enter!
- Beltalowda 4y agoI don't see why; it just has a keybind for Control+G.
- ilyt 4y agoOther example of "running stuff when you just use the shell without pressing enter" is say listing a git branches when you use completion so no. The exploit is "sending something that looks like user input that can also contain ^G"
- bawolff 4y agoI blame xterm. Control sequences should not trigger key presses. That's a recipe for disaster. I think its entirely reasonable for a terminal program to bind any key it wants to execute a command.
- kazinator 4y agoWhat if xterm the text "rm -rf .\n" in response to some character sequence; could we blame the shell, or rm?
- skissane 4y agoxterm is (arguably) implementing ECMA-48 wrong: replies to out-of-band strings (such as OSCs) should themselves be marked as out-of-band (by embedding them in an OSC/APC/DCS/PM, terminated with ST not BEL). Instead it is replying to an out-of-band command in-band. However, I think the design of the Unix tty subsystem is also at fault here - out-of-band messages (OSC/APC/DCS/PM) should be filtered out by default and only delivered to processes which explicitly declare that they are expecting them. That said, if zsh is putting the tty in raw mode, it is saying it wants everything the terminal will send it, so it needs to do that filtering itself.