Support xterm VT sequence (OSC 52) for setting the clipboard

[fpqc]

Mintty and xterm support options to allow setting the clipboard by VT sequences, a feature used by tmux to sync its internal clipboard with the system clipboard. I also wrote the patch for st to add support for setting Xorg's PRIMARY clipboard from VT as well as supporting OSC 52 clipboard setting in tmux if it is emitted from something like vim or a remote nested tmux instance (see patch).

The current code in st is under

strhandle(void)
{
[...]
case 52

in st.c, where it is implemented in a few lines (and the low-level logic is clearer than in my tmux snippet). Notice that the first argument is ignored (since it is only used to read back the system clipboard, which is insecure for reasons spelled out below).

Implementation:
The documentation for this control sequence in xterm is available on invisible-island (see OSC Ps for Ps = 52). The documentation isn't amazing, but essentially the data is emitted as base64 and is decoded back to UTF-8 by base64dec. I don't know how you would implement this into the Windows clipboard, which iirc still uses USC2/UTF-16, but base64dec does give you back a UTF-8 string, and reencoding that to a string compatible with the Windows clipboard is probably something that I think is just handled nowadays by a standard Windows API.

Potential security implications:
I would leave this setting as optional and on a profile-by-profile basis (gated behind an option 'allowClipboardSharing', in case a nasty script emits uses this to try to write data to the clipboard (which at least in the past had been the source of an exploit in an older version of Windows). Note: I would not add support for the read portion of the control sequence (my tmux patch for example simply ignores this case), since this would allow unauthorized reading of the system clipboard.

Example Use Case:
https://sunaku.github.io/tmux-yank-osc52.html

Note that X11 forwarding is not really a desirable option just for clipboard sharing in Windows, given that the Windows clipboard is not an X clipboard, and X11 forwarding theoretically has the same security implications (in fact worse implications).

[egmontkob]

Let me also ephasize the security aspects of this feature.

in case a nasty script emits

It doesn't necessarily mean a malicious script. It could be a poorly coded application combined with an attacker-supplied input, such as OpenSSH's SCP client (bullet points 3 & 4) as discovered recently, or another example mentioned in VTE's issue tracker.

I would leave this setting as optional [...] I would not add support for the read portion

Sounds to me the most reasonable approach, if this feature is implemented at all. Another idea from the VTE bug is to present a popup dialog to confirm setting the clipboard (although it's sure annoying after some time).

[fpqc]

Whenever this spec is implemented, and clipboard-setting from within the terminal is implemented, I think even I (a non-programmer) could write this patch. My only concern is with mixing levels, since I'm not sure if this spec is for the terminal application or for plain conhost, since I think VT processing is done at the level of conhost, rather than at the level of the Terminal, and if the option will be controlled by the profiles.json, I don't know how to turn on a setting at the level of conhost.

[fpqc]

@DHowett-MSFT I was looking through OutputStateMachine.cpp in reference to this comment #2958 (comment) .

You suggested that we actually parse the escape sequence, then fail.

Do you mean in this snippet:

terminal/src/terminal/parser/OutputStateMachineEngine.cpp

Lines 689 to 713 in 1caece7

	switch (sOscParam)
	{
	case OscActionCodes::SetIconAndWindowTitle:
	case OscActionCodes::SetWindowIcon:
	case OscActionCodes::SetWindowTitle:
	fSuccess = _GetOscTitle(pwchOscStringBuffer, cchOscString, &pwchTitle, &sCchTitleLength);
	break;
	case OscActionCodes::SetColor:
	fSuccess = _GetOscSetColorTable(pwchOscStringBuffer, cchOscString, &tableIndex, &dwColor);
	break;
	case OscActionCodes::SetForegroundColor:
	case OscActionCodes::SetBackgroundColor:
	case OscActionCodes::SetCursorColor:
	fSuccess = _GetOscSetColor(pwchOscStringBuffer, cchOscString, &dwColor);
	break;
	case OscActionCodes::ResetCursorColor:
	// the console uses 0xffffffff as an "invalid color" value
	dwColor = 0xffffffff;
	fSuccess = true;
	break;
	default:
	// If no functions to call, overall dispatch was a failure.
	fSuccess = false;
	break;
	}

to add

//Let this control sequence pass through to the attached terminal (if it exists)
case OscActionCodes::SetClipboard:
fSuccess = false;
break;

then just let this this piece of the method dump the whole string through to the attached terminal anyway?

terminal/src/terminal/parser/OutputStateMachineEngine.cpp

Lines 751 to 756 in 1caece7

	// If we were unable to process the string, and there's a TTY attached to us,
	// trigger the state machine to flush the string to the terminal.
	if (_pfnFlushToTerminal != nullptr && !fSuccess)
	{
	fSuccess = _pfnFlushToTerminal();
	}

Where in the cascadia/TerminalApp can we then perform secondary parsing to parse, decode, and then insert this into the clipboard? Does TerminalApp have its own secondary parser or at least a secondary parsing stage that calls the original parser? I don't think I'm experienced enough to add a whole new stage to TerminalApp's program logic if that doesn't exist yet.

If a secondary parsing stage doesn't exist yet, I think I'll have to wait on #1173