OSC 52 is a escape sequence that allows terminal applications to manipulate the system clipboard. For instance, tmux will write such sequences when copying text, if the set-clipboard option is on. The following description is copied from https://github.com/mintty/mintty/issues/258: small rfe, add support for xterm's clipboard OSC paraphrasing from http://invisible-island.net/xterm/ctlseqs/ctlseqs.html Operating System Controls OSC 52 ; Pc ; Pd ST OSC 52 ; Pc ; Pd BEL -> Manipulate Selection Data. The first parameter, Pc, is used to construct a list of selection parameters for clipboard, primary, select, or cut buffers (not important at all). If the parameter is empty, xterm uses s 0 , to specify the configurable primary/clipboard selection and cut buffer 0. (Would be enough to always default to clipboard) The second parameter, Pd, gives the selection data. Normally this is a string encoded in base64. The data becomes the new selection, which is then available for pasting by other applications. (This is important, base64 encoded data should be decoded and saved in the clipboard) If the second parameter is a ? , xterm replies to the host with the selection data encoded using the same protocol.
Should be fairly trivial to implement, look at https://quickgit.kde.org/?p=konsole.git&a=commit&h=bb6abc0bc8a23f46752f7341d43e4275e9085fa9 for inspiration. The question is if this could have security implications.
(In reply to Martin Sandsmark from comment #1) > Should be fairly trivial to implement, look at > https://quickgit.kde.org/?p=konsole. > git&a=commit&h=bb6abc0bc8a23f46752f7341d43e4275e9085fa9 for inspiration. > > The question is if this could have security implications. The terminal emulator Chrome OS displays a "Copied to clipboard" toast when OSC 52 happens, so that the user is always notified. If people feel that this is not secure enough, OSC 52 can be made into a default-off option (but I wish that such a nice feature is not hidden behind configurations...)
See https://bugzilla.gnome.org/show_bug.cgi?id=795774 for some of the security implications (which made VTE not to implement this feature, at least for now). > displays a "Copied to clipboard" toast when OSC 52 > happens, so that the user is always notified Such a notification is easy to miss, e.g. the user takes a break away from the computer. > OSC 52 can be made into a default-off option This could be a reasonable compromise (along with a warning in the prefs about the security implications).
Hello, I fully understand the security implications and I believe this is a good opportunity to contribute with my cybersecurity background :-) Many times we, technical people, look for intelligent technical solutions to security problems. We tend to forget about the human in the loop. You would be amazed knowing how many times not having a feature implemented can be as security risk as well. We have to always balance the pros and cons even. Someone could even not easily understand why not having this feature can be a security problem! The obvious reason is that users wish to transfer data from remote connections. If they can't they'll probably hack their solution without thinking too much about security implications. In this case they could probably ssh-forward the entire X session!!! A correct risk analysis needs to always think about "what will users do if I don't give them access/authorization to a feature they need"? When I can I like to propose solutions when I perform risk analyses. I'll try to propose one here as well. I prefer to think about "how to implement a feature securely?" instead of thinking about "given the risks, shall we implement it?" So, what about a notification that must be clicked (or triggered with a key sequence) within a short timeout before clipboard actions are applied? Like this no clipboard action is performed until the user explicitly allows it, but still remote clipboard actions become possible and available in just a few clicks. This is *secure by default* (nothing happens by default) easy to implement without complex dependencies or algorithms (e.g. cryptography) *minimizes the attack surface* and *does not use secrets*.
There is another solution for remote clipboard support in terminal, already working in real life: the file manager far2l (a fork of Far Manager 2 ported to Linux/BSD/Mac) has a built-in virtual terminal emulator that supports so-called "far2l extensions", including access to the local clipboard. The security problem is solved there as follows: when accessing the clipboard for the first time, terminal displays a message to the user, offering to choose from the following options: "block current attempt to access local clipboard", "do not try to access local clipboard at all", "allow local clipboard access" and "always allow local clipboard access". In the latter case, a random identifier is generated on the remote server, which is memorized by the terminal and used later to authorize access to the clipboard. Of course, this identifier can be leaked, since it is stored unencrypted on server side, so the last option is recommended for use only on servers completely controlled by the user. Just the same logic may be applied then implementing OSC 52 support. Further reading: https://github.com/elfmz/far2l https://github.com/elfmz/far2l/blob/master/far2l/bootstrap/scripts/FarEng.hlf.m4#L1293 https://github.com/elfmz/far2l/blob/master/far2l/VTFar2lExtensios.cpp#L17
As a commenter on the Gnome issue linked says, the bigger use case is setting the clipboard, not reading it, so security problems can and should be significantly motivated by only allowing setting. The app wezterm does so, describing its OSC 52 behavior thus: ``` Requests to query the clipboard are ignored. Allows setting or clearing the clipboard ```
(In reply to unxed from comment #5) > There is another solution for remote clipboard support in terminal, already > working in real life: the file manager far2l (a fork of Far Manager 2 ported > to Linux/BSD/Mac) has a built-in virtual terminal emulator that supports > so-called "far2l extensions", including access to the local clipboard. I forgot to write how the security issue with accessing the clipboard is resolved in far2l. far2l allows you to read the clipboard using special escape sequence only if within the last 5 seconds user pressed Ctrl+C or right-clicked the mouse. If some script tries to read the clipboard on its own initiative, nothing will come of it.
(In reply to andydecleyre from comment #6) > be significantly motivated by only allowing setting. s/motiv/mitig/
I would just like to add that clipboard-setting via OSC52 is an extremely useful feature for terminal-based editors over SSH. See https://github.com/zyedidia/micro/blob/master/runtime/help/copypaste.md. I am very much in favour of this feature being implemented.
Here's a write-only implementation of OSC-52: https://invent.kde.org/utilities/konsole/-/merge_requests/767
I tried to build konsole with that patch and used nvim with ojroques/nvim-osc52 plugin. nvim indicates that it copies something using osc52. But I don't see the result in clipboard after that.
(In reply to Shmerl from comment #11) > I tried to build konsole with that patch and used nvim with > ojroques/nvim-osc52 plugin. nvim indicates that it copies something using > osc52. But I don't see the result in clipboard after that. Are you using tmux by chance? Otherwise, can you see if the following copies the text "copypasta!" to the clipboard, when executed in bash: printf "\033]52;c;Y29weXBhc3RhIQ==\a\n"
(In reply to Christian Muehlhaeuser from comment #12) > Are you using tmux by chance? > > Otherwise, can you see if the following copies the text "copypasta!" to the > clipboard, when executed in bash: > > printf "\033]52;c;Y29weXBhc3RhIQ==\a\n" No tmux, regular konsole. That didn't copy it for me. May be the patch wasn't applied when building? I'll try building it again just to make sure.
OK, it's working! It was my mistake with applying the patch (I had to rebase it for 22.08.3). I noticed one strange thing that when copying in nvim a full line, it adds \n to the copied text as well which is a bit weird, but that can be an issue with the plugin.
Also, trying to copy some more complex code gets pretty messed up. Not sure if it's a problem with konsole implementation or with nvim plugin again.
Some details on copying long text not working: https://github.com/ojroques/nvim-osc52/issues/11
The problem here is that konsole's buffer is limited to 256 characters currently. There's some super hacky code to support inline images, which we could piggyback, but I haven't had the time to clean that up yet.
Yeah, to make this feature a usable alternative to nvim clipboard providers it shouldn't have such small limit.
Is there a reason for 256 buffer limit in general? That sounds extremely small.
I'm unsure why the security considerations is holding this back when KDE has the 'clipboard history', even defaulting to saving the history to disk, in plain text in ~/.local/share/klipper/history2.lst.
(In reply to Wiebe Cazemier from comment #20) > I'm unsure why the security considerations is holding this back when KDE has > the 'clipboard history', even defaulting to saving the history to disk, in > plain text in ~/.local/share/klipper/history2.lst. While clipboard security is not exactly in a good position currently, consider the following aspects: - Containerization is already quite popular for GUI programs too, and those are generally not allowed to just start poking files outside of their own restricted environment. Even if currently unfortunately these programs can just continue snooping on the clipboard even in the background, it's still a good idea to establish at least planned boundaries which may get (better) enforcement in the future. - In the current case if clipboard manipulation would be implemented in Konsole without security cautions, then other hosts being connected to and getting presented the user's terminal would get to have access to the user's clipboard too. Just having to trust the local programs is significantly more palatable than having to trust everything you connect to. - Klipper appears to be somewhat security conscious already as it seems to ignore the clipboard when mime type is "x-kde-passwordManagerHint", usually set by password managers, and usually the clipboard is also cleared shortly after copying. While tighter security would be better as mentioned earlier, these kind of measures already reduce the attack surface. If you are still using X11 then you may be frustrated by not getting another permissionless feature, but the longer term goal is Wayland with permissions where a program sitting in the background without user interaction shouldn't be even able to interact with the clipboard unless it was granted such a permission.
Do those concerns also apply to 'copy TO clipboard'?
(In reply to Wiebe Cazemier from comment #22) > Do those concerns also apply to 'copy TO clipboard'? Not as-is as a write-only approach can't really directly result in information leaking, but the issues regarding unexpected new privilege still stand and I believe those are already quite well described on the very first linked page (mintty issue). It's a lower hanging fruit for sure, but not low enough to just force the functionality on everyone by default, it should start at least with an option to enable it which defaults to being disabled. Main point was to address the odd conclusion about local clipboard security including possibly having clipboard history saved, even though the most interesting use case would be programs running on different hosts which obviously have no access to anything you mentioned. Likely it's a good idea to look at how browsers handled this matter as there's a clipboard web API, and foreign hosts can't just decide to fiddle with the clipboard as for example even simple writing is limited: "Transient user activation is required. The user has to interact with the page or a UI element in order for this feature to work." There's a security vs convenience trade-off here, and while ideally we could enjoy the best of both worlds with finer grained permissions like the earlier mentioned approach of programs not being interacted with by the user not being allowed to use the clipboard (if not given some extra permission), that's not a solution we'll see any soon, so have to be careful with adding new features which come with risks unexpected by the majority of the users. For example I used to conveniently paste multi-line snippets in some cases, but then I switched to Konsole which supports bracketed paste mode, so my approach stopped working which also meant that malicious multi-line clipboard payloads became a significantly less threatening risk. It's safe by default with the option of disabling the safety feature for possibly more convenience.
Yknow what would be better than TALKING ABOUT IT FOR S E V E N Y E A R S DOING IT If security is a concern (it's really not, OSC52 is supported by almost every popular terminal now), make it optional and default to off. Simple.
(In reply to pallaswept from comment #24) > Yknow what would be better than TALKING ABOUT IT FOR S E V E N Y E A R S > > DOING IT Fantastic idea. Looking forward to your contributions!
(In reply to Christian Muehlhaeuser from comment #25) > (In reply to pallaswept from comment #24) > > Yknow what would be better than TALKING ABOUT IT FOR S E V E N Y E A R S > > > > DOING IT > > Fantastic idea. Looking forward to your contributions! As I look forward to yours.
(In reply to pallaswept from comment #26) > (In reply to Christian Muehlhaeuser from comment #25) > > (In reply to pallaswept from comment #24) > > > Yknow what would be better than TALKING ABOUT IT FOR S E V E N Y E A R S > > > > > > DOING IT > > > > Fantastic idea. Looking forward to your contributions! > > As I look forward to yours. I mean seriously, you provided half of this almost a year ago and it's still sitting there being ignored, like WTF? It doesn't take 7 years to plan it and it doesn't take a year to merge it. This happens aLOT on bugs.kde.org, you end up with cases where people literally sit around talking about how to do it for 10 years and nothing ever happens. I'm the guy who fixes that problem by calling out how stupid it is.
(In reply to Christian Muehlhaeuser from comment #25) > (In reply to pallaswept from comment #24) > > Yknow what would be better than TALKING ABOUT IT FOR S E V E N Y E A R S > > > > DOING IT > > Fantastic idea. Looking forward to your contributions! Another thing that happens a lot on bugs.kde.org are developers who have the knowhow to fix the problem expecting end users to write the code because they asked for a feature, usually masked as an 'invitation' such as "patches welcome!" or "looking forward to your contributions". You don't need to be passive-aggressive about it, if you want help, ask. I'll say yes.
(In reply to pallaswept from comment #28) > (In reply to Christian Muehlhaeuser from comment #25) > > (In reply to pallaswept from comment #24) > > > Yknow what would be better than TALKING ABOUT IT FOR S E V E N Y E A R S > > > > > > DOING IT > > > > Fantastic idea. Looking forward to your contributions! > > Another thing that happens a lot on bugs.kde.org are developers who have the > knowhow to fix the problem expecting end users to write the code because > they asked for a feature, usually masked as an 'invitation' such as "patches > welcome!" or "looking forward to your contributions". You don't need to be > passive-aggressive about it, if you want help, ask. I'll say yes. Hey you have some valid criticism, but please don't charge in like an angry bull and expect to be received well.
(In reply to SC from comment #29) > (In reply to pallaswept from comment #28) > > (In reply to Christian Muehlhaeuser from comment #25) > > > (In reply to pallaswept from comment #24) > > > > Yknow what would be better than TALKING ABOUT IT FOR S E V E N Y E A R S > > > > > > > > DOING IT > > > > > > Fantastic idea. Looking forward to your contributions! > > > > Another thing that happens a lot on bugs.kde.org are developers who have the > > knowhow to fix the problem expecting end users to write the code because > > they asked for a feature, usually masked as an 'invitation' such as "patches > > welcome!" or "looking forward to your contributions". You don't need to be > > passive-aggressive about it, if you want help, ask. I'll say yes. > > Hey you have some valid criticism, but please don't charge in like an angry > bull and expect to be received well. Don't be soft if I was charging like an angry bull you'd know all about it. Just because I'm being honest and direct and keeping it real doesn't imply I'm angry, nor does it give anyone any excuse to not receive me well - on the contrary, I ought to be appreciated for being honest and direct and trying to get something done instead of faffing about for a decade.
Any new on this? With distributions defaulting to Wayland there is no way to copy/paste from a remote ssh session anymore. A workaround is to use waypipe but that is suboptimal...
I would appreciate some update on this too. Is there some way to help with this? What has to be implemented / improved for this to work? Something about kosnole buffer?
Apparently some downstream distros are working around this by changing the buffer size: -#define MAX_TOKEN_LENGTH 256 // Max length of tokens (e.g. window title) +#define MAX_TOKEN_LENGTH 65536 // Max length of tokens (e.g. window title) That might cover all cases (like very large selections) but it's still better than 256 characterless. Is there a problem to changing that default to something like a few megabytes altogether?
(In reply to Shmerl from comment #33) > Apparently some downstream distros are working around this by changing the > buffer size: > > -#define MAX_TOKEN_LENGTH 256 // Max length of tokens (e.g. window title) > +#define MAX_TOKEN_LENGTH 65536 // Max length of tokens (e.g. window title) I'm surprised to hear that, as I don't think changing this constant actually has any effect. It looks like a remnant that was forgotten to be removed and it's not actually used anywhere.
Well, I see it being used at least in a few places in the code: ``` src/Vt102Emulation.cpp:322: tokenBufferPos = qMin(tokenBufferPos, MAX_TOKEN_LENGTH - 1); src/Vt102Emulation.h:127:#define MAX_TOKEN_LENGTH 256 // Max length of tokens (e.g. window title) src/Vt102Emulation.h:132: uint tokenBuffer[MAX_TOKEN_LENGTH]; // FIXME: overflow? ``` But I didn't dig extensively through it. Trying to build it now with that change to see if it does anything.
It's definitely helping! I was able to copy 27,637 bytes now when testing copying some random text, unlike without the patch.
So I'd say it's worth looking into that, or even making this buffer dynamic when you need to handle osc52 altogether and set some limits which are defined separately.
(In reply to Shmerl from comment #35) > Well, I see it being used at least in a few places in the code: > > ``` > src/Vt102Emulation.cpp:322: tokenBufferPos = qMin(tokenBufferPos, > MAX_TOKEN_LENGTH - 1); > src/Vt102Emulation.h:127:#define MAX_TOKEN_LENGTH 256 // Max length of > tokens (e.g. window title) > src/Vt102Emulation.h:132: uint tokenBuffer[MAX_TOKEN_LENGTH]; // FIXME: > overflow? > ``` That looks like an outdated version of the code. Looking at the git history, it seems like this issue may have been fixed a few weeks ago and the tokenBuffer now gets resized to fit the content. I've got to take a closer look, but that might enable me to revisit this issue. Either way MAX_TOKEN_LENGTH is definitely obsolete now.
(In reply to Christian Muehlhaeuser from comment #38) > (In reply to Shmerl from comment #35) > > Well, I see it being used at least in a few places in the code: > > > > ``` > > src/Vt102Emulation.cpp:322: tokenBufferPos = qMin(tokenBufferPos, > > MAX_TOKEN_LENGTH - 1); > > src/Vt102Emulation.h:127:#define MAX_TOKEN_LENGTH 256 // Max length of > > tokens (e.g. window title) > > src/Vt102Emulation.h:132: uint tokenBuffer[MAX_TOKEN_LENGTH]; // FIXME: > > overflow? > > ``` > > That looks like an outdated version of the code. Looking at the git history, > it seems like this issue may have been fixed a few weeks ago and the > tokenBuffer now gets resized to fit the content. I've got to take a closer > look, but that might enable me to revisit this issue. Either way > MAX_TOKEN_LENGTH is definitely obsolete now. Right, I should have clarified, I was doing it with Debian testing's konsole which is behind recent versions (due to Debian being in the middle of time_t 64-bit migration monstrosity and KDE maintainers not updating things often). https://tracker.debian.org/pkg/konsole But that's regardless, if the new code isn't using that define, it's still might have the limit somewhere. So you can get the idea what can be increased?
> tokenBuffer now gets resized to fit the content If that's the case - then great! May be your patch will just work then.
I'll check if I can backport those recent commits and your osc52 patch to the older konsole in Debian testing, to be able to use that before it's updated there: * https://invent.kde.org/utilities/konsole/-/commits/master/src/Vt102Emulation.h?ref_type=heads * https://invent.kde.org/utilities/konsole/-/commits/master/src/Vt102Emulation.cpp?ref_type=heads
That didn't work unfortunately due it using some unavailable Qt functionality for that version.