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 795774 - Add support for OSC 52
Add support for OSC 52
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-05-03 14:38 UTC by Raul
Modified: 2021-06-10 15:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Raul 2018-05-03 14:38:15 UTC
OSC 52 control code can be used to copy text into the clipboard.

tmux has native support for the OSC 52 sequence. See `man tmux` https://linux.die.net/man/1/tmux under the set-clipboard setting.

If gnome terminal could support OSC 52 it would remove the reliance on xclip or xsel and copying in tmux would work regardless of ssh tunnels.
Comment 1 Raul 2018-05-03 14:39:28 UTC
Also wanted to point out that VTE  has support for parsing the escape code: https://git.gnome.org/browse/vte/tree/src/parser-osc.hh#n85
Comment 2 Egmont Koblinger 2018-05-04 20:34:14 UTC
Whereas it really sounds like a cool feature if used properly, we should also consider the possible harm (e.g. security/privacy implications) if used maliciously.

http://invisible-island.net/xterm/ctlseqs/ctlseqs.html says "These controls may be disabled using the allowWindowOps resource." In the Ctrl + right-click menu, Allow Window Ops is unchecked for me, yet querying the selection works. What am I missing? Should we maybe implement this as an opt-in feature in g-t?

When ssh'ing to a malicious (compromised) remote site, this feature automatically grants read/write access to your selection and clipboard to the attacker. This might be used for them to retreive sensitive data (whatever you're working with and copy-pasting, e.g. in a document editor), to spam (e.g. place links to malicious sites in the clipboard), or to mangle the contents in seemingly innocent ways (e.g. overwriting URLs to a lookalike).

Well, all these (plus more, e.g. looking at your entire screen) can be done now if X11 forwarding is enabled. But we'd extend these for the no X11 forwarding, plus the Wayland cases too.
Comment 3 Raul 2018-05-04 21:43:35 UTC
There was some good discussion here too: https://github.com/mintty/mintty/issues/258
Comment 4 Raul 2018-05-04 22:17:45 UTC
If security is a concern, I would vote for only implementing writing to the clipboard, not reading. Reading from the clipboard shouldn't be necessary since you can always Ctrl+Shift+C to paste.
Comment 5 Egmont Koblinger 2018-05-04 22:24:34 UTC
(In reply to Raul from comment #4)

> I would vote for only implementing writing to the clipboard

This is a nice improvement, still, I wouldn't want a compromised site (or app) to be able to place "rm -fr *" in my clipboard (as mentioned in the mintty issue you linked).
Comment 6 Egmont Koblinger 2018-05-04 22:35:23 UTC
Just one example: I relatively often use mpg123 to listen to local mp3's, sometimes even to live radio streams. It never occurred to me previously, just now: what if the ID3 tag (e.g. song title) contains escape sequences? Guess what: they're sent raw to the terminal emulator. That is, a maliciously crafted mp3 file or live stream played using mpg123 could then place that rm command in my clipboard. I'll file a bugreport against mpg123, but I'm quite certain there are dozens of similarly careless apps out there which open up this door to attackers.
Comment 7 Egmont Koblinger 2018-05-07 21:47:25 UTC
(mpg123 bug reported: https://sourceforge.net/p/mpg123/bugs/267/)
Comment 8 Christian Persch 2019-04-16 16:16:56 UTC
May be instructive to take a look at https://www.w3.org/TR/clipboard-apis/ .
Comment 9 Tony Houghton 2019-04-16 16:33:23 UTC
One way this could be made optional is if vte raised signals for these events instead of manipulating the clipboard itself, then it could be up to g-t, roxterm etc how to handle it. They may be able to provide some sort of feedback to the user that the clipboard has been set by the terminal and is therefore potentially unsafe.
Comment 10 Hippie Hacker 2020-05-22 18:31:38 UTC
I'm unsure where this conversation should be /stay. I saw the migration and wanted to make sure this got some visibility:

https://gitlab.gnome.org/GNOME/vte/-/issues/125

I'm pulling my initial comments over here to see if they are of use!

OSC 52 control code can be used to copy text into the clipboard.

tmux has native support for the OSC 52 sequence. See `man tmux` https://linux.die.net/man/1/tmux under the set-clipboard setting.

If gnome terminal could support OSC 52 it would remove the reliance on xclip or xsel and copying in tmux would work regardless of ssh tunnels.

VTE  has support for parsing the escape code: [_VTE_OSC(XTERM_SET_XSELECTION, 52)](https://gitlab.gnome.org/GNOME/vte/blob/master/src/parser-osc.hh#L85)

[w3 clipboard-apis](https://www.w3.org/TR/clipboard-apis/) might also be an informative read.

It's been stale for a while, but I'm interested in getting a conversation up on gitlab, since we've moved here -https://bugzilla.gnome.org/show_bug.cgi?id=795774
Comment 11 Hippie Hacker 2020-05-22 18:49:06 UTC
I've noticed that in some web based terminals, there is to be a popup noting 'clipboard populated' message.

iTerm2 I think may have a similar feature / setting.

There has also been some recent traction for getting OSC52 support into Microsoft's new terminal as well:
https://github.com/microsoft/terminal/pull/5823

I'm keen to help if I can, mainly interested in everyone multiple people sharing a remote session (via ssh/tmux/tmate) and being able to populate everyones local OS clipboard across linux/Mac/windows.
Comment 12 Egmont Koblinger 2020-05-22 19:54:12 UTC
I think the work should continue by studying comment 8.

There are webpages that populate the clipboard upon a click (e.g. github/gitlab copies the repository link). We should study how that works, what are the security/privacy concerns it has, whether it can be misused for an innocent-looking mouse click (e.g. attempting to follow a link) to place "rm -rf" there, or if it can even be done without clicking.

I'd say anything that's already doable by a malicious webpage is fair game, but anything that designers of the web decided not to have has already received a red flag and should be treated with according caution.

(To be fair: a malicious app placing an "rm -rf *" is not the real problem, since – obviously – everyone has a backup of their data, correct? :-) The real problem is the "upload your personal documents and sensitive files to a remote site"-like or "install a backdoor"-like commands, which can even take the form of "curl unique-url | sh" where the file behind this unique-url vanishes after the first download, so good luck tracking down what actually happened to your system right after you accidentally ran this command.)

> there is to be a popup noting 'clipboard populated' message.

Desktop notification popups are short-lived, easy to miss. I don't find this a sufficient compensation for a security-wise problematic feature.

> mainly interested in everyone multiple people sharing a remote session [...] and being able to populate everyones local OS clipboard across

I'm afraid I don't understand your exact setup, but it smells to me exactly the security-critical scenario.

Security/privacy and convenience usually work against each other, it's always a hard decision to find the right balance. I'm really concerned how other terminals go for the maximum convenience here and completely ignore the security/privacy aspects.
Comment 13 Egmont Koblinger 2020-05-22 20:18:03 UTC
> vanishes

Or, well, gets replaced by something truly innocent.
Comment 14 Christian Persch 2020-05-22 21:48:50 UTC
OSC 52 looks very much like the 'asynchronous clipboard API' from the spec in comment 8, a very powerful API with huge security and privacy implications.

If we want to implement something like this in vte, *at a minimum* we will need to first implement a permissions model [inspired by https://w3c.github.io/permissions/] and make clipboard access contingent on user's explicit permission grant. (And hook up gnome-terminal to that permissions model, with UI.)

And I'd also want to explore whether this 'clipboard' should be the actual system (i.e. wayland, X) clipboard, or be a 'local' clipboard, i.e. a per-terminal storage area, where moving data to/from the system clipboard would require further, explicit user interaction.
Comment 15 Christian Persch 2020-05-22 21:55:21 UTC
BTW, a permissions model would also be a requirement to adding notifications (like the OSC 777 ones that the fedora patch uses). So that'd be a good starting point.

> VTE  has support for parsing the escape code: [_VTE_OSC(XTERM_SET_XSELECTION, 52)]

The define here only means that we know that this number is assigned; vte has no code actually handling it further.
Comment 16 Egmont Koblinger 2020-05-22 22:19:17 UTC
> And I'd also want to explore whether this 'clipboard' should be the actual system (i.e. wayland, X) clipboard, or be a 'local' clipboard, i.e. a per-terminal storage area, where moving data to/from the system clipboard would require further, explicit user interaction.

This is a nice, interesting idea; could be a replacement for the permissions model. (I don't see the details yet, it just feels promising.)
Comment 17 martin H. 2020-05-26 23:16:37 UTC
I think a real permission model like on the web is hard, unless we want to add some exciting new sequences that use data signed by a machine (or user or ...) specific key(i.e. have public keys as "origins" for the permission model).

Of course there could be a per tab permission thing.

There might not be a one size fits all solution, so possibly we want to give users a bit of options.

The currently widely deployed model on the web is that clipboard write access on interaction (click or keypress) is available to all sites without any permission prompts.

I think we can model this in the terminal use case too:
* Keyboard input and mouse clicks set a "may set clipboard flag"
* focus loss unsets the "may set clipboard flag"
* optionally: writing to the clipboard unsets the "may set clipboard flag"
* optionally: using the terminal UI to set clipboard contents (i.e. edit -> copy) unsets the "may set clipboard flag"
* writing to the clipboard is possible (say via OSC 52) if the "may set clipboard flag" is set. The terminal will show a inline UI indicator. This indicator is only needed so users can wait until it's shown before switching to a different application in support of higher latency ssh connections.

This will prevent terminal sessions from spamming the clipboard with malicious content while the user is working in other applications, while still allowing fairly smooth working in low latency situations. Increasing latency then needs increasing amounts of attention from the user, but there is not much we can do about this, because the user has to wait for the full latency anyway.

This model also does not allow much more than what is possible via the web. (It allows to be arbitrary slow in response to a user gesture. This would need blocking the javascript thread in browsers which ends in a tab not responding modal in browsers). It's hard to restrict this further (i.e. not allowing screen updates between the user interaction and setting the clipboard because of the asynchronous nature of terminal communication)

Of course there are a lot of possible variations. For example the first time in a tab that the clipboard is set, there could be a UI element that allows choices like "always allow", "allow for this tab", "allow once" or even "allow without interaction".

But i think this is not strictly needed if we just want to be as safe as the current practice in web browsers.
Comment 18 ldrumm 2020-12-13 01:28:37 UTC
Apologies for the cross-post. I commented on the gitlab dup. Reproduced here:

I've taken a shot at this which I think should satisfy both sides of the security discussion. A patch is attached. I'd welcome thoughts and suggested improvements if it seems reasonable.

``` 
 [RFC] Support OSC-52 integration with the clipboard
    
    This patch provides an initial implementation of OSC-52 support
    following the behaviour of xterm.
    
    This might be a viable candidate fix for #125 [1]. I've tried to keep it
    flexible, but safe in the default configuration - leaving matters of
    security policy to library consumers. To make this simple, and
    dynamically configurable, there are two new public functions in
    `vte-terminal.h`:
    
        vte_terminal_set_allow_clip_read()
        vte_terminal_set_allow_clip_write()
    
    The existing  discussion [1] on this proposed feature focuses on W3C
    guidelines for cliboard acccess rights, but I think its better to leave
    the decision to enable this feature to the application; mechanism, not
    policy. The web is very different from running native applications in an
    unconstrained terminal. This is likely the most common case for VTE. Any
    matters of security policy can be offloaded.
    
    The present implementation is straightforward and requires no extra
    dependendencies, relying on glib for base64 codecs and existing
    clipboard handling APIs in VTE itself.
    
    [1](https://bugzilla.gnome.org/show_bug.cgi?id=795774)

```
[0001-RFC-Support-OSC-52-integration-with-the-clipboard.patch](https://gitlab.gnome.org/GNOME/vte/uploads/0f6c9e635070d8072b3dabf70823789c/0001-RFC-Support-OSC-52-integration-with-the-clipboard.patch)
Comment 19 Christian Persch 2021-01-18 21:13:20 UTC
> I've taken a shot at this which I think should satisfy both sides of the security discussion.

It doesn't. I thought I'd been clear in comment 14 that I don't think a global on/off switch is good enough here.

--

Let me go into a bit more detail how I think this should work (under the assumption that this is a good feature to have, which I'm not convinced of!).

First, there should be global API to en/disable this (like your patch has); plus hooking that up to vte-2.91 under a *separate* switch (not window ops).

Then, there should be the permissions object, VtePermissionRequest, which should be an opaque object accessed only through the provided API. It should have an enum for which type of permission is requested (CLIPBOARD_READ, CLIPBOARD_WRITE, ...).

When one of these sequences is encountered, and the setting is 'off', vte should just respond with an error message / an "empty clipboard" reply. If it's 'on', VteTerminal should emit a new 'request-permission' signal with a new VtePermissionRequest object as parameter, and then the UI should prompt the user for permission (ALLOW/DENY) which is communicated back to VteTerminal. If denied, same as when the global pref is off; if allowed, then VteTerminal will do the work internally (set the system clipboard with the provided text for 'clipboard write', or request the clipboard contents (asynchronously) and on receipt output the sequence to the application, for 'clipboard read').

A complete patch will also actually hook this UI up in the vte-2.91 test application. Perhaps using popovers on the copy/paste buttons to prompt the user for permission to write/read the clipboard.

--

As for the protocol itself, I don't like it since it has several deficienies:

* There is no need for a special OSC sequence to provide the clipboard contents to the application; we already have the 'bracketed paste' mode and so can just send CSI 200 ~ [TEXT] CSI 201 ~ instead of base64 encoded text.

* base64 is wasteful encoding. We rely on the channel being 8-bit clean, so why not use an 8-bit protocol, or, if we absolutely need a 7-bit protocol, we could use base94/95/96 to transport at 6.5 bits per byte instead of just 6, at least.

* The vte OSC control string limit of 4k unichars plus the base64 overhead means that we can only transport short clipboard contents (3k bytes, *not* even characters). Relaxing this limit isn't acceptable; analogous to the changes recently made to the parser to accomodate long DECSIXEL sequences without enlarging that limit, will be needed for OSC sequences, meaning more extra work.
Comment 20 ldrumm 2021-01-28 00:30:53 UTC
On Mon Jan 18, 2021 at 9:13 PM GMT, vte (GNOME Bugzilla) wrote:
> https://bugzilla.gnome.org/show_bug.cgi?id=795774
>
> --- Comment #19 from Christian Persch <chpe@gnome.org> ---
> > I've taken a shot at this which I think should satisfy both sides of the security discussion.
>
> It doesn't. I thought I'd been clear in comment 14 that I don't think a global
> on/off switch is good enough here.
>
> --
>
> Let me go into a bit more detail how I think this should work (under the
> assumption that this is a good feature to have, which I'm not convinced
> of!).
>
> First, there should be global API to en/disable this (like your patch has);
> plus hooking that up to vte-2.91 under a *separate* switch (not window ops).
>
> Then, there should be the permissions object, VtePermissionRequest, which
> should be an opaque object accessed only through the provided API. It should
> have an enum for which type of permission is requested (CLIPBOARD_READ,
> CLIPBOARD_WRITE, ...).
>
> When one of these sequences is encountered, and the setting is 'off', vte
> should just respond with an error message / an "empty clipboard" reply. If
> it's 'on', VteTerminal should emit a new 'request-permission' signal with a
> new VtePermissionRequest object as parameter, and then the UI should prompt
> the user for permission (ALLOW/DENY) which is communicated back to
> VteTerminal. If denied, same as when the global pref is off; if allowed, then
> VteTerminal will do the work internally (set the system clipboard with the
> provided text for 'clipboard write', or request the clipboard contents
> (asynchronously) and on receipt output the sequence to the application, for
> 'clipboard read').

This sounds like a lot of work for something that's highly likely to infuriate
most users. Not even web browsers behave like that. The shell running in the
terminal - and its children - most likely have access to the
filesystem without permission requests, and I can think of precisely zero other
native applications that ask for clipboard access like this. Imagine the
following session:

1. "^C: gedit wants to access your clipboard for copying"
2. "^V: firefox wants to access your clipboard for pasting"
3. "^C: Do you want to allow Libre-Office to access the system clipboard"
4. user rage-quits and installs Windows

The closest thing I can think of is webcam and microphone requests on the web,
but the privacy implications of allowing a native application to read or write
the clipboard are not comparable to your webcam being exposed on the web.

If a *consumer* of libvte wants to do something like that with the API proposed:
more power to them. That will be easy to support with the present design, but
requiring consumers of your library to adhere to your user interface guidelines
seems like precisely the wrong approach. Like I said in my original post:
"Mechanism, not Policy".

>
> A complete patch will also actually hook this UI up in the vte-2.91 test
> application. Perhaps using popovers on the copy/paste buttons to prompt the
> user for permission to write/read the clipboard.
That's fine. I'd be willing to donate my time to do this in VTE *the
application*, but not the library.
>
> --
>
> As for the protocol itself, I don't like it since it has several
> deficienies:
>
> * There is no need for a special OSC sequence to provide the clipboard
> contents to the application; we already have the 'bracketed paste' mode and so
> can just send CSI 200 ~ [TEXT] CSI 201 ~ instead of base64 encoded text.

This patch is for applications which speak OSC-52; nothing else.

>
> * base64 is wasteful encoding. We rely on the channel being 8-bit clean, so
> why not use an 8-bit protocol, or, if we absolutely need a 7-bit protocol, we
> could use base94/95/96 to transport at 6.5 bits per byte instead of just 6, at
> least.

Base64 is what OSC-52 uses.

> * The vte OSC control string limit of 4k unichars plus the base64 overhead
> means that we can only transport short clipboard contents (3k bytes, *not*
> even characters). Relaxing this limit isn't acceptable; analogous to the
> changes recently made to the parser to accomodate long DECSIXEL sequences
> without enlarging that limit, will be needed for OSC sequences, meaning more
> extra work.
>
I tried following the protocol for OSC-52 here as closely as possible for
interopability. The OSC-52 protocol's pretty ugly, but any in-band signalling
protocol has issues. I don't think cooking up a new incompatible protocol which
breaks all applications that speak OSC-52 in order to satisfy buffer limitations
in VTE is the right approach.

> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 21 Kevin Cox 2021-01-28 18:49:13 UTC
> The shell running in the terminal - and its children - most likely have access to the filesystem without permission requests

That is an assumption that we can't make. I regularly SSH into machines that I don't trust as much as my local machine and they *must not* get access to my clipboard without permission.

> This patch is for applications which speak OSC-52; nothing else.

I can get behind wanting to support the protocol that exists, even if it isn't optimal. However how widely adopted is the protocol? Maybe it does make sense to implement the feature with an improved protocol?

That being said, unless it is going to add much maintenance burden it is probably better to support OSC-52 at least until a better protocol is implemented.
Comment 22 GNOME Infrastructure Team 2021-06-10 15:31:39 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2495.