Re: bracketed-paste-mode should default to "off"

[Karl O. Pinc]

Hello,

After digesting everyone's responses and examining the readline code I
have some observations, a suggestion, and various bits of what might
be useful information.  I am new to readline, so could be wildly
wrong, and welcome comments and corrections.  First, the observations.

The primary point of bracketed paste is to produce as pasted text the
actual content of the clipboard.  The primary object being to guard
against interpretation of the clipboard content as readline commands,
which un-intentionally alter the paste result.  In addition to
guarding against simple accident (i.e., I imagine, TAB, typically),
this guards against the cutting and pasting of malicious content.  A
particular concern because the characters typically bound to readline
commands are unprintable and so "invisible".  This is the primary
threat bracketed paste addresses.

A "side effect" is that newline is not immediately acted upon, newline
being bound to a readline command.  This, in turn, guards against a
different threat, allowing review of pasted content and the editing
out of malicious content before it is passed to the calling
application.  A different threat of secondary benefit, although when
googling it seems that many, if not most, see this as the primary
point of bracketed paste.

Although bracketed paste addresses 2 different threats, it seems to me
that it need not.  This is supported by another observation: The only
reason why newline is handled specially by readline, or rather, why
the accept-line command exists, is because command line editing
exists.  If command line editing, history, etc., did not exist,
entering a newline would always result in a newline at the end of the
stream of character input, regardless of the cursor's position on the
visible line due to terminal control characters.  Given that bracketed
paste disables all readline commands, there is no need for bracketed
paste to also handle newline in a special way.  When nothing is
special, newline need not be special.

The following patch against devel/HEAD, a proof of concept which could
be wrong, demonstrates this.  It causes newline to be acted upon
immediately when in bracketed paste mode, eliminating the "side
effect" of delaying acting on newlines -- and opening up
opportunities.

--- a/kill.c
+++ b/kill.c
@@ -825,6 +825,8 @@ _rl_bracketed_read_key ()
            _rl_unget_char ((unsigned char)pbuf[pblen]);
        }
       xfree (pbuf);
+      if (c == '\n')
+        rl_newline(0, c);
     }
 
   return c;


(Caution, the original code indents with tabs.)

One opportunity is to make readline simpler.  There is no longer any
need for bracketed paste to highlight (etc.) the pasted text/active
region; there is no point.

But of course the threat of "un-reviewed pasted content" is no longer
mitigated.  Having introduced a feature that addresses this threat,
there will, no-doubt, be people who do not want to give it up.  If
this feature is important the opportunity can be taken to re-introduce
it with a "delay-pasted-newline" setting, which would only have effect
when bracketed paste is on.  [Writing

if (! _rl_delay_pasted_newline && c == '\n') ...

instead of the "if" given above.]  In this case the pasted text would
be highlighted when both modes are on.

I see advantage to having the 2 different threats addressed by two
different features.  It provides more control, allowing for a more
fine-grained tuning of the trade-offs between security and
ease-of-use.

My suggestion is to take one of the two paths above.


And now, for the incidental feedback.  No need to respond to any of
this unless you think it useful.

As you know, I find that delaying acting upon newline makes the user
interface harder to use.  One reason is that I have all highlighting
and colorization and so forth very distracting and have it turned off.
My brain just wants to focus on the highlights etc. and comprehension
drops precipitously.  Regardless, highlighting the pasted text, text
that otherwise looks like it should execute, is visually meaningless
without prior experience.  There's no way to know that the pasted
line(s) are not executing or what to do to make them execute.
Delaying newline comes with an ease-of-use cost.  I'd be hard to argue
that pasting the actual content of the clipboard comes with any cost
and it surely has large potential benefit.  So I argue for separating
the two.

The above makes me think that someone who knows more than me should
think about the impact, if any, of all this on people with
disabilities.

In a vaguely related way, if it hasn't happened already, someone
should think about what it means to paste into something like a
password prompt, where all input is suppressed.  (Not to get into
whether passwords should be pasted, or even exist.)  Or situations
where dots are printed for every character input.  I've not paid any
attention to terminal control sequences in years so I might just be
being paranoid, but I imagine there could be interactions between such
things and whatever's done to indicate "the active input area".

(Maybe "dots" are not an issue, the application not seeing the paste
until after enter is pressed?  Again, IMO, in-itself sort of a weird
thing to have to do -- pressing enter just to get the app to show
dots.  When I do paste passwords I usually include a trailing newline
in the paste, just to keep things moving that much faster.  And here's
there's no possibility of a visual cue that newlines are delayed, or
actually become part of the pasted text.  Possibly, another argument
for a setting that turns off delayed reaction to newlines while
letting readline commands remain disabled.  I've not thought this one
through.)

FYI, FWIW, I've had confusion in the past just having a terminal
accidentally left in bracketed paste mode (after pressing ^C while
entering passwords?).  I forget the details but was testing remote
access and had to repeatedly enter long passwords.  Bracketed paste
turned into a not-insignificant time-suck; I thought the problem was
with the process I was working on.

Yes, when I wrote in my original email that "paste did not work", that
meant that extra action was needed to cause bash to execute the paste.
Bracketed paste mode was on and newline needed to be pressed after
pasting.

My distro (Debian) did present the readline NEWS to me.  But
"bracketed paste mode" meant nothing to me.  I suspect many users
share my ignorance.  When I do a major release upgrade I'm presented
with many pages of NEWS.  I look it over, but it's unrealistic to look
up every unknown concept.  Even when there's an obvious place to go
looking up terms, concepts, and technologies it's unrealistic to spend
even a few minutes to understand the implications of every change made
to every one of the upgraded packages.  My system has been through
numerous upgrades and has 2,687 packages installed.

It is non-obvious, to me at least, that newline is bound to a readline
command, because I think of newline as shell syntax.  (Of course, it
is both.)  My point is that if you want your NEWS entries to be useful
they need to describe the implications of your changes in ways that
connect with the users experience.  This is really hard and probably
more than can be expected; we want authors to focus on their code.
You might have to accept that no one is going to be educated until
they get bonked on the head by a change.

Regards,

Karl <kop@karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein