[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] bracketed paste support

From: Daniel Colascione
Subject: Re: [PATCH] bracketed paste support
Date: Wed, 29 Oct 2014 21:42:31 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 10/29/2014 09:35 PM, Pádraig Brady wrote:
> On 10/27/2014 10:35 PM, Daniel Colascione wrote:
>> address@hidden enable-bracketed-paste
>> address@hidden enable-bracketed-paste
>> +If set to @samp{on} and the terminal supports bracketed paste mode,
>> +configure it to insert each paste into the editing buffer as a string
>> +instead of treating the characters pasted as normal input, preventing
>> +inadvertent execution of pasted commands.  The default is @samp{on}.
> I see this defaults on.
> Does this mean one can't paste command sequences to readline now?

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.

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]