After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 753197 - Filter out control chars when pasting
Filter out control chars when pasting
Product: vte
Classification: Core
Component: general
git master
Other Linux
: High major
: vte-0-42
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Reported: 2015-08-03 21:00 UTC by Egmont Koblinger
Modified: 2018-04-01 19:34 UTC
See Also:
GNOME target: ---
GNOME version: ---

Fix (3.01 KB, patch)
2015-10-04 02:22 UTC, Egmont Koblinger
none Details | Review

Description Egmont Koblinger 2015-08-03 21:00:24 UTC
You can paste control chars such as U+03 (^C interrupt), U+04 (^D EOF) and so on. So pasting data from an untrusted source to e.g. a "cat" command is potentially harmful, it may terminate "cat" and execute arbitrary stuff. Or lock up your terminal (U+13 ^S scroll lock) and you have no clue why. Or start visual effects such as coloring the text...

xterm swallows these chars while pasting. I guess we should too.

(Note: slightly related, obviously more problematic due to usability regression is the newline char: bug 697571).
Comment 1 Egmont Koblinger 2015-08-16 11:18:41 UTC
U+80..U+9F should be dropped as well for the same reason (and xterm drops them too).
Comment 2 Christian Persch 2015-09-26 18:47:40 UTC
Comment 3 Egmont Koblinger 2015-10-04 01:42:21 UTC
xterm swallows control chars except \r, \n, \t, ^H and ^?. Also in 8-bit mode it filters out 0x80-0x9F. In UTF-8 mode it lets U+0080-U+009F pass through because it doesn't recognize them as C1. We do handle them as C1, so we need to filter them out too in every charset.
Comment 4 Egmont Koblinger 2015-10-04 02:22:58 UTC
Created attachment 312618 [details] [review]
Comment 5 Egmont Koblinger 2015-10-06 20:32:40 UTC
chpe, what do you think, shall this patch be backported? Just as much as it's security (=> yes), it changes the behavior (=> no).
Comment 6 Christian Persch 2015-10-07 20:52:04 UTC
At least backport to 0-42 is fine, IMHO.
Comment 7 Egmont Koblinger 2015-10-07 22:13:10 UTC
I either backport all the way to 0-36, or not at all :D
Comment 8 Egmont Koblinger 2015-10-12 19:02:02 UTC
Missed the tarball creation, and it's only been tested on my machine so far, so committed to master only.
Comment 9 Ting-Wei Lan 2017-01-08 08:12:26 UTC
Can we have an option in vte and gnome-terminal for users to manually enable control character pasting? I know xterm disables it by default, but you can enable it by running it with "xterm -xrm 'XTerm*vt100.AllowPasteControls: true".

I agree that it should be disabled by default to prevent it from being used in malicious ways, but pasting control characters does have some valid usecases.

1. Pasting a plain text file that is colored with control characters. Control characters are still widely used in telnet-based BBS to have basic formatting for articles. Some people even use control characters to create images and animations with text.

2. Automate key pressing. Not all programs run in a terminal have a scripting interface, and you will need another program to generate key-pressing events if you want to do the same tasks hundreds of times. If we allow pasting control characters, it can be much easier. Write all keys you want to press in a text editor. Copy and paste them to the terminal, wait for a few seconds, and your work is done.
Comment 10 Egmont Koblinger 2018-03-24 13:03:17 UTC
Continuing in bug 794653.
Comment 11 Egmont Koblinger 2018-03-29 16:23:27 UTC

Answering here, as this bug is somewhat more relevant to your problem than 794653.

I'm not explicly against having such an option, but I'm not for it either, and I have no intent to work on this. XTerm has way more options than we do, and I don't think it's the right approach (nor practically maintainable in the long run) to have one for every tiny bit of preference. This particular one sounds like a truly obscure one to me, probably relevant to extremely few people. There are other possible workarounds (e.g. xdotool on X11 that can also insert pauses), and – even though conceptually I hate to say this – as long as you're the only one requesting this feature, maybe the best is if you stick to an older VTE, or patch this feature, or use xterm instead. (Let's also note that a VTE-based app could also work around this limitation by feeding the corresponding bytes, so technically, your desired change could also go to any VTE-based app, not necessarily to VTE. Chances are that simple utilities similar to script, or maybe screen or tmux could also easily inject predefined sequences on a certain event.) Unfortunately we cannot please everyone (it's unreasonable to even try), and I'm sorry but personally I feel like this one could remain unresolved. (But I'm not the project's main guy to have the final word.)
Comment 12 Egmont Koblinger 2018-04-01 19:34:19 UTC
Just for the record: Another important aspect of this fix (not mentioned here earlier) was that prior to this fix it was possible to break out of bracketed paste mode (if the pasted data contained its terminating sequence), so pasting wasn't even safe into bracketed paste aware apps. (See e.g.