[Pkg-urxvt-maintainers] Bug#787628: Bracketed paste is unsafe

[Marc Lehmann]

On Mon, Nov 16, 2015 at 04:46:07PM +0100, Yuri D'Elia <wavexx at thregr.org> wrote:
> 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.

I understand what you wish for, but I think you are trying to use the
wrong tool here. For starters, can you define what "as-is" means when the
data is binary and the terminal is in utf-8? Or a non-utf-8 filename?

> 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.

And with filtering it is also not possible to implement this "reliably".

> Bracketed paste might actually be used by editors, such as vim, to
> insert text as-is without having to enter "paste" mode first.

The problem with this is that a large share of pastes would not benefit
from paste mode. It's basically only _some_ multiline pastes that would
benefit from it, while most would either not benefit or suffer negative
effects from it.

> We've been discussing the issue of break processing in the zsh ml, and
> 
> 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.

zsh doesn't have access to the pty master, and is unlikely to be able to
react fast enough.

> 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.

The problem isn't that it is guessing, the problem is that is always wrong
- if a program sends different text when asked for a selection then what
the user has selected, this is a bug, which can be security-relevant. No
amount of kludging or guessing or following protocol can fix this in a
terminal emulator, unless the temrinal emulator suffers from the same
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.

Didn't you just write that zsh doesn't? And why would that be proper
behaviour? The number of times where I paste actual commands into my
shell completely dwarfs the few times where I paste hidden commands from
insecure apps such as firefox - or in other words, the only way to switch
zsh into proper mode would be to disable an option that would put it into
"proper mode".

This is going the same path as firefox - instead of plugging javascript
security holes, we get kludges (such as disabling file urls because
firefox can't guarantee their safety, or randomly renaming your profile
directory instead of keeping javascript from snooping around in your
filesystem).

I very much disagree that keeping the user from pasting text that she or
he wants to paste is proper - it's just more bossing around because actual
bugs (like the one in firefox) don't get fixed.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\