Support clipboard via OSC 52

[yurikhan]

Many terminal emulators, starting with Xterm, conditionally allow access to the system clipboard via an escape sequence. In comparison with xclip-based solution (#30), this works transparently when you ssh around, without X11 forwarding and without having to install xclip on each server you manage.

To write to the clipboard, an application sends ESC ] 5 2 ; c ; <content> ESC \, where <content> is base64-encoded. (BEL can also be used as terminator.)

To read the clipboard, an application sends ESC ] 5 2 ; c ; ? ESC \. A conforming terminal will respond by sending ESC ] 5 2 ; c ; <content> ESC \, again, with <content> base64-encoded. (If the request uses BEL instead of ESC \, the terminal’s response will typically also be terminated with BEL.)

A non-supporting but ANSI-conforming terminal will ignore the unsupported OSC sequence until the ESC \ or BEL terminator.

I do not think there is a termcap/terminfo capability advertising support, so it would probably have to be a user option. Alternatively, mc could unconditionally put copied content into both ~/.local/share/mc/mcedit/mcedit.clip and send the OSC sequence; when pasting, first send the request, and if no response within a few milliseconds, fall back to reading ~/.local/share/mc/mcedit/mcedit.clip.

[zaytsev]

Wow, this would be cool! What do you think andrew_b? I wonder what's the current state of the terminal support for this feature...

[yurikhan]

I must admit my “Many terminal emulators” assessment is skewed towards emulators aimed at power users. Xterm (opt-in via config), Kitty (opt-in via config), Alacritty, iTerm2 (warns); tmux (opt-in via config). Support in libvte and KDE’s implementation seems to be stuck on the security issues; basically, “a compromised ssh server could steal passwords by polling your clipboard” and “a compromised ssh server could put a malicious command into your clipboard which you might then execute locally or on a different server”.

[dataman]

Replying to yurikhan:

I must admit my “Many terminal emulators” assessment is skewed towards emulators aimed at power users. Xterm (opt-in via config), Kitty (opt-in via config), Alacritty, iTerm2 (warns); tmux (opt-in via config).

In addition: contour, wezterm, foot and "modern" Windows Terminal.

[dataman]

The implementation from ​https://craigbarnes.gitlab.io/dte editor.
​https://gitlab.com/craigbarnes/dte/-/blob/master/src/terminal/osc52.c:

bool term_osc52_copy(TermOutputBuffer *output, const char *text, size_t text_len, bool clipboard, bool primary)
{
    BUG_ON(!clipboard && !primary);
    size_t bufsize = (text_len / 3 * 4) + 4;
    char *buf = malloc(bufsize);
    if (unlikely(!buf)) {
        return false;
    }

    term_put_literal(output, "\033]52;");
    if (primary) {
        term_put_byte(output, 'p');
    }
    if (clipboard) {
        term_put_byte(output, 'c');
    }
    term_put_byte(output, ';');

    if (unlikely(text_len == 0)) {
        goto out;
    }

    size_t remainder = text_len % 3;
    size_t ilen = 0;
    size_t olen = 0;
    if (text_len >= 3) {
        ilen = text_len - remainder;
        BUG_ON(ilen == 0);
        BUG_ON(ilen % 3 != 0);
        olen = base64_encode_block(text, ilen, buf, bufsize);
    }

    if (remainder) {
        base64_encode_final(text + ilen, remainder, buf + olen);
        olen += 4;
    }

    term_put_bytes(output, buf, olen);

out:
    free(buf);
    term_put_literal(output, "\033\\");
    return true;
}

[zaytsev]

Any idea what's the situation with VTE & KDE?

[dataman]

Replying to zaytsev:

Any idea what's the situation with VTE & KDE?

Konsole-git - yes: ​https://github.com/KDE/konsole/commit/9f7a2b846afbf3d34d10c224a9f3b32ce7aa1379

VTE - I don't know.

[dataman]

And welcome to ​https://www.linux.org.ru/forum/desktop/17750458 :)

[zaytsev]

And welcome to

Thanks, but I don't have time to join any more communities. Besides, this one is registration only and the ambience doesn't suit my communication preferences.

[egmont]

VTE refuses to implement OSC 52 due to its known security issues.

See its tracker bug ​https://gitlab.gnome.org/GNOME/vte/-/issues/2495 for more details, although a great summary of these security problems have already been given here.

There also have been two proposals there to fix those security problems. Hardly anyone (if at all) other than the designers of these two protocols have shown any interest in chiming in, have a word which one would be the better, let alone some other terminals' developers or some apps showing any interest in joining the game, eventually replacing their problematic OSC 52 with a fixed protocol. One or both of those protocols (I can't recall off the top of my head) might also need buy-in from ssh implementations, or from shell startup scripts shipped by distros; if that's the case then it doesn't sound like an easy ride.

There was a request to implement a more generic framework in VTE that would allow VTE-based emulators to hook up and handle any OSC any way they want to, but given that the obvious goal of this feature request is to allow such VTE-based emulators to implement OSC 52 with its known security problems, and given that it wouldn't solve app-initiated copy-pasting in GNOME Terminal (whose development goes hand-in-hand with VTE, i.e. would refuse to implement OSC 52), VTE developers are reluctant to implement this generic framework, too.

Maybe the right thing would be for VTE to arbitrarily pick one of the two proposals and just go ahead and implement, and then wait for apps to adapt. Dunno. I'd love to work on it if I saw a significant interest from involved parties, but since I don't see any, I'm personally not really motivated to work on it.

So: unless the wider community (i.e. some other key terminal emulators as well some key applications) show interest and put in work into fixing its security aspect, VTE is likely to remain without app-initiated copy-paste support.