Re: [PATCH] bracketed paste support

[Daniel Colascione]

On 10/30/2014 06:05 AM, Bob Proulx wrote:
> Daniel Colascione wrote:
>> Well, I don't know whether Chet left the feature enabled by
>> default. I hope he did, though, since preventing execution of pasted
>> commands is one of the feature's key benefits. In bash, you should
>> be able to execute a pasted command sequence by typing RET after the
>> paste, but a paste by itself should never begin execution.
> 
> I use paste into the shell with an embedded newline in order to
> immediately execute a command *a lot*.  If that were removed I would
> be very unhappy.

I strongly doubt that your use case is typical. I've asked several of my
colleagues; all have complained about accidentally pasting a large
amount of text into the shell at one time or another. Nobody has
complained about losing automatic execution of code after paste.
Speaking from personal experience, I've been using terminal emulators of
various sorts for almost 20 years, and in that time, I've accidentally
pasted documents into my terminal orders of magnitude more often than
I've deliberately pasted multi-command sequences.

As far as I'm concerned, automatic execution of code on paste isn't a
feature: it's a bug and security hole. Users should have to opt into
security holes. We've only lived with the existing behavior so long
because it's only recently become possible to distinguish pastes from
other input.

> However I read from Chet's replies that this is not the case.  So I am
> not worried.  Just voicing a counter opinion that this shouldn't be
> removed.

Nobody is talking about removing the ability to select the present
behavior. We're talking about the default setting.

> If you want it then you should enable it.  This is like many
> other options available in the shell.  They are optional.

This feature significantly decreases the likelihood of user error, but
if it's not on by default, most users won't enable it and won't see any
benefits. I'd rather slightly power users like you with very specific
use cases than continue to see accidental code execution.

>> For better or worse, people copy and paste commands from websites
>> all the time. Even if a bit of shell looks innocuous, a malicious
>> bit of JavaScript could change the pasted text at the last second
>> without the user being aware of the switch. 
> 
> Then the browser shouldn't copy it.  The place to fix the problem is
> in the browser.  

Browser behavior is unlikely to change; even if it did, sequences of
text that look safe can contain control characters like TAB that invoke
various shell commands. Visually inspection is not a reliable way to
inspect a piece of code pasted from an otherwise-untrusted source.

Sure, you might argue that users should paste into a trusted
intermediate location --- say a text editor --- inspect the code, and
then paste into the shell. That would be the prudent thing to do, but
users don't actually *do* that and never will.

> A problem with a browser should not break cutting and
> pasting in general.

This change doesn't "break" pasting. It changes its behavior to one
that's safer, more natural, and more consistent with that of other programs.

>> (Tynt uses this technique to slightly less malicious ends.) If
>> pasting in a terminal immediately begins execution, there's no
>> opportunity to review pasted code. With bracketed paste support, the
>> shell requires additional user interaction after a paste to begin
>> execution, making this attack much less effective.
> 
> I am very happy this is a feature you like.  However I would hate that
> feature.  It should definitely not default to on or it will make
> people like me very unhappy.

You can disable the setting yourself. If you don't want to do that, all
you need to do is type RET after pasting. That's a very small tradeoff
for an increase in safety and predictability.

signature.asc
Description: OpenPGP digital signature