On 10/29/2014 09:42 PM, Daniel Colascione wrote:
> On 10/29/2014 09:35 PM, Pádraig Brady wrote:
>> On 10/27/2014 10:35 PM, Daniel Colascione wrote:
>>
>>> +@item enable-bracketed-paste
>>> +@vindex 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 effective.
Requiring the extra RET after pasting shouldn't be too onerous.
I found this to be a good summary:
http://cirw.in/blog/bracketed-paste
Thanks for the extra info!
Pádraig.
