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

[Marc Lehmann]

I'll take this off debians bugtracker now, it really makes no sense to
discuss this there (it's not a discussion forum), the bug should be
reassigned to firefox and/or other programs that suffer from this security
issue, as it can't be fixed in a terminal emulator. Or closed.

If you want to discuss development of urxvt with me, please do so on the
urxvt list (rxvt-unicode at lists.schmorp.de>), or with me privately.

On Tue, Nov 17, 2015 at 02:37:54PM +0100, Yuri D'Elia <wavexx at thregr.org> wrote:
> On 17/11/15 00:32, Marc Lehmann wrote:
> >> 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?
> 
> Encoding sits on top of the construct if we can make the paste
> transparent, it won't change the current status quo.

If that were true, nobody would ever have an encoding problem - the problem
is, it isn't true. Grafting encoding on top of a system that doesn't support
it will just result in more mojibake, not correct behaviour. I don't see a
point in supporting something that is broken to begin with.

The problem of bracketed paste is that people are asking for things
that are badly specified, badly implemented, badly thought out and with
ill-defined goals.

> If we agree that the current scheme is insufficient for any purpose,
> let's break it for the better. There's basically no-one using bracketed
> paste currently.

That could mean there is little or no demand for it. It's also not clear
what the purpose of it is - everybody, including you, cites security
concerns of some form as reason, i.e., they don't have a real use case.

> > zsh doesn't have access to the pty master, and is unlikely to be able to
> > react fast enough.
> 
> A proper solution might actually to devise on how the pasted content
> should be encoded by the bracketed paste in a way that 1) allows
> embedded control sequences of any kind 2) they are escaped for the
> terminal discipline to pass-though.

I can't see how that would be a proper solution (see above).

> In that sense, we could just encode the block in a 7bit-safe encoding
> such as base64 or something more efficient.

escaping or using hex would be a lot more conservative, just saying.

> > 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.
> 
> Not really. Bracketed paste allows to make the distinction between a
> human typing and a paste, and that really makes a great difference.

Such as? You make a lot of very remarkable claims, but so far have shown
very little to back them - which is something in common with the faction that
wants to "fix" bracketed paste.

> >> 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".
> 
> zsh now enables bracketed paste by default.

So you redact your claim? I am not sure what you mean with this statement,
it doesn't seem to be a reply to the quoted text.

> It actually sends \e[?2004l to all terminals, as the ones we tried that
> didn't support bracketed paste simply swallowed the escape.

Basing such behaviour on a few terminal (emulators?) you tried is hardly
a good implementation. It's really just a bad hack - what's next,
zsh-certified terminals, and everybody else has lost?

(Hint, this only works on ansi/vt-type terminals).

> A bracketed paste is also never executed by default. A newline is
> inserted literally (as ^J would), so that any command can be previewed.
> The paste is also quoted and the quoting style can be customized with a
> prefix argument, so that you can paste into a quote with quotes being
> escaped correctly, and invisible characters can always be seen.
> 
> It's a major improvement in behavior for pasting in any sense.

It would be a major step back for me, so your statement is wrong. Again, it
is ea to make sweeping statements such as these, but more is needed to
convince me, especially when the claims turn out to be wrong.

> > 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.
> 
> I doubt firefox will ever be able to fix this issue in a way that makes
> "copying" safe.

A good first step that might be all that is needed is to not select text that
the user hasn't selected. That should be near-trivial to implement, and bears
no more difficulty than click-through prevention or similar problems already
taken care of.

In any case, whether firefox will be able to fix this isn't really the
issue - firefox is the *only* place where even an attempt to fix it can be
made.

> Frankly, I do not care, as unicode issues will always be present.

What kind of unicode problems in terminals/shells etc. do you think of
here? And what is the connection of unicode issues to the existing security
problem (which has nothing to do with unicode)?

Your argument is of the form "let's not fix this security problem, because
other security problems might exist". I think this is a non-starter.

> Let's fix bracketed paste.

I am not sure it is broken, and quite unconvinced that a solution is easy
to achieve.

The bigger problem (the only thing bracketed paste is being requested for
afaics) is the security issue, and the fix for that can't be implemented
by bracketed paste.

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