Vim paste totally screwed up.

cfr · 2023-01-09 02:16:55

seth wrote:

And they're wrong.
Don't copypaste stuff from the internet directly into interactive shells.
It is, to quote schard, "a monumentally bad idea".
You're oc far more likely to get away w/ that from a nice dude on the bbs or stackoverflow (if there're multiple views/responses) than from reddit or, worse, 4chan or some random dudes blog.
But it is *never* safe.

I understand that after reading this thread, but I doubt it is common knowledge.

seth wrote:

echo foo | xsel -i
and then paste (Shift+ins) into your terminal.

I don't actually have an insert key. I noticed above different kinds of paste being mentioned, so I'm not sure what's equivalent. If I copy-paste that and press enter, I just get

bash: xsel: command not found

Thanks for the information about vim.

Last edited by cfr (2023-01-09 02:19:45)

dikei · 2023-01-09 07:13:16

Corresponding Debian bug report.

https://groups.google.com/g/linux.debia … 0oCUoLFNFQ

Vim's bug report
https://github.com/vim/vim/issues/11766

Apparently, this bug is already fixed in a newer version of Vim (patch 9.0.1117)

Last edited by dikei (2023-01-09 07:17:27)

Head_on_a_Stick · 2023-01-09 07:18:03

seth wrote:

But it is *never* safe

Don't be silly. It is perfectly safe if you know exactly what the command does and you use the PRIMARY to copy it. That just saves time typing and is immune to the javascipt hack, which relies on the CLIPBOARD.

seth · 2023-01-09 08:18:44

The point about bracketed pasting is to catch stealth glyphs that are sneaked in there via various html shenanigans.
Ie you *believe* to exactly know what the command does, but you don't, because you don't know what you actually copied.

This is NOT limited to javascript:
https://www.bleepingcomputer.com/news/s … et-hacked/

the article schard linked wrote:

A Reddit user also presented an alternative example of this trick that requires no JavaScript: invisible text made with HTML and CSS styling that gets copied onto your clipboard when you copy the visible portions of text:
"The problem is not just that the website can change your clipboard contents using JavaScript," explains the user, SwallowYourDreams.
"It could also just hide commands in the HTML that are invisible to the human eye, but will be copied by the computer."

Also, reality check: if you copypaste commands from the internet, that's usually because you don't exactly know what they do.
Your shell will hopefully catch that, but I'm sure you're aware what a trivial fork-bomb looked like.
How hard, do you suppose, would it be to hide that and a stray semicolon and hashtag in your garden varienty, average complex sed string?

If you copypaste stuff from the internet into an interactive shell, you allow somebody else to operate your system.
You can justify that w/ "I think this seth guy has a very trustworthy looking avatar", but it is not safe to do that.
Your browser is NOT a friendly environment.

Head_on_a_Stick · 2023-01-09 16:26:58

I stand corrected. Thanks seth :-)

Trilby · 2023-01-09 16:36:21

But but but, I use w3m. So you're WRONG!

seth · 2023-01-09 20:05:58

So tabby's dead?

seth wrote:

Your browser is NOT a friendly environment.

apparently not the author of tabby wrote:

i use w3m

--- q.e.d.

Before anyone finds this thread and freaks out:
The world isn't full of monsters.

99.999% of all times you copy stuff from a webpage, it's probably benign.
Eg. I'd be hard pressed to come up w/ a way how one could trick the clipboard within the context of the BBS (because, unlike markdown, you can't post literal html) and also too many savvy users hang out here to not, at least after a while, catch a deceptive command, call it out and flag it for deletion.

But: you need to be very aware of the security layers around you - and when they're absent.
It is therefore risky to create the habit to casually copy and paste from the internet - even in a safe™ environment.
Because those habits will stick and bite you (not gonna tell where) in the 0.001% case when pasting stuff from the internet was a *really* dumb idea.

So be cautious and mindful where, how and from whom you pick up a piece of code.
Every. Single. Time.

Trilby · 2023-01-09 20:25:45

Actually tabby is currently on life-support due to huge API changes in wlroots 0.15->0.16 ... but tabby is my compositor, not browser (weaver is my browser project).

seth · 2023-01-09 21:16:46

So… I guess we just figured that I use neither - and that being too lazy (to research it) bit me…

dfogni · 2023-01-09 21:46:28

Is there any point in non-trivial paste-handling by terminal applications/emulators, beside fixing "copy from a browser might have injected something invisible into the buffer"?

The html shenanigans reasoning seems little more than a security failure on the browser side. That js can do the same without giving trusted feedback of the final content is even worse behaviour, again of the browser alone.

Why is the browser not warning the user that the copied (plain version of the) text is the result of very different text elements and is therefore unsafe?
Or just shows a pop-up with a single scrollable text box and a couple of buttons "yup this is what I wanted to have in my clipboard", "no, I wrongly clicked somewhere", "NO! Report the address of this page for fraudulent clipboard behaviour, and never let me visit it again"?

If the user is one that ignores a warning he does not understand, he surely would not be able to understand why the terminal is doing or asking anything more than just pasting.

Trilby · 2023-01-09 21:52:00

I'd have all the same questions as above. This security "feature" would also prevents copying and pasting multiple commands at once which one might want to do. I say would as this "feature" has never existed on my systems. I just use xsel / wl-paste to check the contents of the buffer before posting - there's not even a need for a browser to check this either.

A security measure that's in place for something on the order of one in every thousand or so copy operations that interferes with all one thousand is a bit silly - even more so when a ounce of care from the user would prevent every problem in those one-in-one-thousand cases.

chen · 2023-01-09 22:01:57

Most likely an ncurses-related issue. The latest patch of ncurses (https://lists.gnu.org/archive/html/bug- … 00020.html) stated:

+ add comment to bracketed+paste explaining that vim patch 9.0.1117 is needed for use with the updated xterm descriptions (suggested by Bram Moolenaar).

I guess the issue might be fixed when the latest vim lands in the package repository.

seth · 2023-01-09 22:20:32

The origin of bracketed pasting isn't security related at all: https://cirw.in/blog/bracketed-paste
That became a thing in 2020/2021 or so.

Trilby · 2023-01-09 22:26:38

How does that link indicate it's not security related? It seems to clearly show it is as it is a response to:

[copy-and-pasting into a terminal] can obviously be dangerous as your shell has the ability to do all kinds of things that you don’t want to happen by accident.

seth · 2023-01-09 22:33:25

Sorry, https://invisible-island.net/xterm/xterm-paste64.html

Edit: I was also wrong about when this first became a security thing - despite readline defaulting to it ~2020/1, it's clearly already concerned in 2013.
Bed-time.

Last edited by seth (2023-01-09 22:37:43)

Trilby · 2023-01-10 00:11:01

Thanks for the new link. But this history brings into doubt the relevance of bracketed paste for this thread. Apparently bracketed paste has been around for a while; this problem arose (or was revealed) only with the an update to ncurses. So perhaps it's a bug in code that implements bracketed paste, but it's not bracketed pasting itself that is the issue. Further support of this conclusion is that I apparently do not have bracketed paste in my terminal, yet I was impacted by the current problem pasting into a terminal.

jasonwryan · 2023-01-10 01:06:50

The latest ncurses has also screwed up the prompt position on opening a terminal. For some god unknown reason, the prompt is now halfway down the screen. So now I have to Ctrl-l in every terminal I open because my OCD will not let me begin typing halfway down a screen...

cfr · 2023-01-10 05:32:00

jasonwryan wrote:

The latest ncurses has also screwed up the prompt position on opening a terminal. For some god unknown reason, the prompt is now halfway down the screen. So now I have to Ctrl-l in every terminal I open because my OCD will not let me begin typing halfway down a screen...

I didn't see that in konsole, even without borrowing the old terminfo definitions.

jasonwryan · 2023-01-10 05:39:49

cfr wrote:

jasonwryan wrote:
The latest ncurses has also screwed up the prompt position on opening a terminal. For some god unknown reason, the prompt is now halfway down the screen. So now I have to Ctrl-l in every terminal I open because my OCD will not let me begin typing halfway down a screen...
I didn't see that in konsole, even without borrowing the old terminfo definitions.

Yep, it's a urxvt thing. I haven't had the time, or the will, to dig into it.

Toolybird · 2023-01-10 06:51:04

> it's a urxvt thing

https://bugs.archlinux.org/task/77062

jasonwryan · 2023-01-10 06:54:35

Toolybird wrote:

> it's a urxvt thing
https://bugs.archlinux.org/task/77062

Ta!

seth · 2023-01-10 15:30:29

Trilby wrote:

So perhaps it's a bug in code that implements bracketed paste, but it's not bracketed pasting itself that is the issue.

Since it's the terminfo that seems to trigger this and the terminfo 6.3/6.4 diffand last 6.3 patch almost exclusively tackle brackted pasting for various terminal emulators it is probably around the topic.
The debian thread claims that vim 9.0.1117 will "fix" (align to) this and independently of that, it would probably still be a good idea to test whether bracketed pasting in general still (or now) works as can be expected (and compare it w/ the toggleable readline behavior)

ilf0 · 2023-01-12 14:48:33

It's a vim issue: https://github.com/vim/vim/issues/11766
It's fixed upstream in 9.0.1117: https://github.com/vim/vim/commit/7b8db … 0e3e0a49fd

Here's the Arch vim package bug: https://bugs.archlinux.org/task/77043?p … string=vim
Testing already has 9.0.1182, fixing this: https://archlinux.org/packages/testing/x86_64/vim/

Last edited by ilf0 (2023-01-12 14:51:58)

Evil_Hamster · 2023-01-15 23:38:30

Sorry all for not writing earlier. Was bit busy. After the update, everything seems to be fine, so I will leave things as they are. It really seems to have been a bug.

Thanks to all for the many informative replies, I did follow them, even when I was not writing.

Cheers all.

Arch Linux

#26 2023-01-09 02:16:55

Re: Vim paste totally screwed up.

#27 2023-01-09 07:13:16

Re: Vim paste totally screwed up.

#28 2023-01-09 07:18:03

Re: Vim paste totally screwed up.

#29 2023-01-09 08:18:44

Re: Vim paste totally screwed up.

#30 2023-01-09 16:26:58

Re: Vim paste totally screwed up.

#31 2023-01-09 16:36:21

Re: Vim paste totally screwed up.

#32 2023-01-09 20:05:58

Re: Vim paste totally screwed up.

#33 2023-01-09 20:25:45

Re: Vim paste totally screwed up.

#34 2023-01-09 21:16:46

Re: Vim paste totally screwed up.

#35 2023-01-09 21:46:28

Re: Vim paste totally screwed up.

#36 2023-01-09 21:52:00

Re: Vim paste totally screwed up.

#37 2023-01-09 22:01:57

Re: Vim paste totally screwed up.

#38 2023-01-09 22:20:32

Re: Vim paste totally screwed up.

#39 2023-01-09 22:26:38

Re: Vim paste totally screwed up.

#40 2023-01-09 22:33:25

Re: Vim paste totally screwed up.

#41 2023-01-10 00:11:01

Re: Vim paste totally screwed up.

#42 2023-01-10 01:06:50

Re: Vim paste totally screwed up.

#43 2023-01-10 05:32:00

Re: Vim paste totally screwed up.

#44 2023-01-10 05:39:49

Re: Vim paste totally screwed up.

#45 2023-01-10 06:51:04

Re: Vim paste totally screwed up.

#46 2023-01-10 06:54:35

Re: Vim paste totally screwed up.

#47 2023-01-10 15:30:29

Re: Vim paste totally screwed up.

#48 2023-01-12 14:48:33

Re: Vim paste totally screwed up.

#49 2023-01-15 23:38:30

Re: Vim paste totally screwed up.

Board footer