Re: [vim/vim] feat(osc52) clipboard (PR #20896)

dezza left a comment (vim/vim#20896)

> thanks for working on this and thanks for careful thinking of exfiltration attacks. 

Thanks sincerely for your *always valued* input @chrisbra and greatly appreciated continued effort in maintaining and handling everything (*also the smaller side-projects and aspects which I can only imagine are larger than most think !*)

> Assuming enabling osc52 handling does not add much code for vim tiny, wouldn't it be much more useful to always enable this for tiny builds

> I think we should instead make use of `:set clipmethod` even in tiny mode, so that users can selectively enable and disable the feature as they need it. 

Try `grep -R FEAT_CLIPBOARD` its basically a very large chunk of what makes `FEAT_NORMAL`+.

> instead of giving distributions the choice to disable it for their own tiny vim? 

Its my wish and intention, that they look positively on this and embrace it - also why I am hesistant to rush it, but lets imagine for a moment, that this lands first as somewhat of a sleeper-feature (*dormant, word of mouth, builds hype*), matures and gets feedback and we listen to the major, common distro concerns. 

* Would they opt for just "*patching it out*" ? That would be a loss of trust. This why I've postponed this so many times and kept pondering about the best approach.

Honestly, I still believe writing openssh mailing list and *hoping*(🦜) for a positive and caring response would yield best results long-term, even if it initially seems unlikely. 

It would remove the hindrance of distributions flat out rejecting it, because they are afraid of being called out, or compared, (*or whatever*).

With approval and access-controls in `.ssh/config` from openssh it would be *much more commonly accepted* and less feared.

> On another point, how well is OSC52 actually supported by terminals nowadays? I read that writing to the clipboard is even more widely supported than reading the clipboard by terminals (for the same security concerns)? Is that true?

> And finally, I am not so sure the `$VIMOSC52` is a good choice. 

*Let me clarify:*

* Env var is not to promote usage of env vars as config
* Promotes easy enabling without prior muscle-memory or knowhow of arguments.

*Argument:*
I think it might be underestimated by us, how many actually *never* configure vim, but use it as like a "fixed/maintained" `vi` on some server somewhere. This is the reason why I thought the env var makes it more accessible, easy to use and requires no initial memory or concern regarding configuring. I think, if a fellow sysadmin showed this trick, it would be a talking point, something worth sharing.

... lets investigate [how many envvars are actually read right now](https://github.com/search besides the usual suspects `DISPLAY,PATH,LINES,LC_*,XDG_*` which are merely state/userenv.

[netbeans.c](https://github.com/vim/vim/blob/62c8cdc37c2a1b3ef825022cfa343d5c16019831/src/netbeans.c#L172-L200) is by far the largest user of envvars.

[os_win32.c](https://github.com/vim/vim/blob/62c8cdc37c2a1b3ef825022cfa343d5c16019831/src/os_win32.c) has a few.

A quick sweep follows of support (*not verified 100%, take with grain of salt - just did a quick search and tried to find sources*):

### Terminal support

---

Read+write support:
* xterm - *default: off*
* Alacritty - *default: write*
* Ghostty - *default: write* `+access_dialog`
* Foot - *default: off* (https://codeberg.org/dnkl/foot/src/branch/master/config.c#L1232-L1239)
* Kitty - *defaults: write* `+access_dialog`
* mintty - *defaults: unknown*
* iTerm2 - *default: off*  `+access_dialog` (https://iterm2.com/3.4/documentation-escape-codes.html)
(*seems like iTerm have changed to the less standard `OSC 1337` in 3.5 (https://iterm2.com/3.5/documentation-escape-codes.html*) *\*sigh\**

Write only support (*defaults not checked*):
* tmux
* Windows Terminal
* Konsole
* hterm (*ChromeOS Secure Shell*)
* st
* WezTerm

---

Stumbled upon a good writeup with considerations here: https://miliucci.org/post/linux-terminals-osc-52-escape/ the best part argument;
`The dangerous read-from-clipboard OSC 52 method is also the less useful because, in graphical environments, you can just press Ctrl+Shift+V and paste the clipboard content in your terminal without the need of an escape sequence. It is the Desktop Environment that will handle it for you and pass the clipboard content to the application (the terminal in our case).`

tl;dr conclusion of article:
`Almost all terminal emulators support the OSC 52 escape sequences. They do it safely using different security frameworks based on user confirmation, static configuration, temporal authorization and so on. It is disappointing that the most popular Linux Desktop Environment does not support it in the default terminal application used by millions (Gnome Console). The same is true for the default terminal (Ptyxis) of popular developers oriented distributions like Fedora.`



-- 
Reply to this email directly or view it on GitHub:
https://github.com/vim/vim/pull/20896#issuecomment-5151209513
You are receiving this because you are subscribed to this thread.

Message ID: <vim/vim/pull/20896/[email protected]>

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/vim_dev/vim/vim/pull/20896/c5151209513%40github.com.