Sorry for the late reply, but as I wasn't included in the reply, I didn't get any notification. I just stumbled upon it today by chance...
> First of all, the safety is not the same as security, and the bracketed > paste mode is not a means for security (for a variety of subreasons, the > main being that pasting a _shell_ command that contains data that the user > doesn't know is insecure with or without bracketed paste mode filtering > out certain sequences). The way I see it, bracketed paste allows the program attached to the tty to receive clean input from the paste without the terminal interfering. Ideally, I would like the data to come through *as-is*, 8bit clean. Unfortunately, bracketed paste is flawed, as it relies on a termination sequence and doesn't allow escapes. This means that even if I wanted to, I cannot pass input that includes the termination sequence. Without filtering the termination sequence at all, there's *no* way to implement reliably *any* bracketed sequence. It *is* the job of the terminal program to filter the sequence, and only that sequence, from the paste. This is not sanitization of the input, it's just protocol. > Third, even if bracketed paste mode would single out this sequence, it's > not a security feature, as the user has no feedback on whether this mode > is enabled, so cannot base her decision to paste on this mode. Advertising > bracketed paste mode as a security feature would trick users into unsafe > behaviour. This patch was produced as a result of some work in zsh, which now uses bracketed paste to automatically quote (and not execute by default!) pastes. This is now the default behavior in zsh since 5.1. Bracketed paste might actually be used by editors, such as vim, to insert text as-is without having to enter "paste" mode first. However, bracketed paste needs to be reliable. > Lastly, guessing what is "safe" and what is "unsafe" in the terminal > emulator is the wrong place, as it can't know what the application > interprets. For example, the application might abort paste mode on other > sequences as well (such as ctrl-c). It's also very difficult to implement, > even if there was a list of what is to be filtered out, as the patch > shows, which doesn't manage to filter out sequences at internal borders, so > not giving the false impression that pasting is safe no matter what it > contains. We've been discussing the issue of break processing in the zsh ml, and indeed the patch is still "incomplete" in the sense that Ctrl+C is still processed by the terminal discipline, and that's definitely something that should be avoided. I'd rather try to manually change and restore the terminal mode through the pty master in order for the bracketed paste to be fully transparent for all programs, but I didn't get to it yet. I don't want to go through the route of xterm, which instead filters the input "pretending" to know what is safe and what isn't, which like you say, is just guessing. > Therefore, I would suggest reassigning this to firefox or other > applications in Debian GNU/Linux that let you select one text visually, > but then offer a different text as the selection to other apps, as that is > indeed a security problem. Firefox has nothing to do with it here, but it shows one of the most important aspects of a reliable bracketed paste: if bracketed paste is implemented correctly in the terminal, proper behavior *can* be implemented at the application level, as zsh now shows.
