Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copy Paste from editor over SSH - OSC 52 support #2198

Open
luzik opened this issue Nov 29, 2023 · 3 comments
Open

Copy Paste from editor over SSH - OSC 52 support #2198

luzik opened this issue Nov 29, 2023 · 3 comments

Comments

@luzik
Copy link

luzik commented Nov 29, 2023

As more and more console editors make use of "OSC 52" please consider supporting it by tilix

neovim/neovim@748bc4d

@egmontkob
Copy link

(I'm not a Tilix developer but I'm a VTE developer.)

Tilix uses the VTE widget for terminal emulation.

VTE developers deliberately refuse to add OSC 52 support because of its known security/privacy problems. At least two protocols that would fix these problems have been proposed, but no one had the resources yet to implement them and start convincing other terminals and apps to follow.

In the mean time, shame on every terminal emulator and every terminal-based application that adds OSC 52 support, despite its well-known security flaws. They should all deliberately reject to implement it, and cooperate to design and drive the adoptation of a new, safe solution. My 2 cents.

@luzik
Copy link
Author

luzik commented Nov 29, 2023

Thank you for clarification.
As I am aware of security concerns, in my environment they do not apply - I own all the machines involved. It would be awesome to have option like '--enable-unsecure-osc52' until something betters comes in. Especially in one way - editor can write to clipboard without read capabilities - this options seems to be safer.

@egmontkob
Copy link

I understand you. And I'm still a bit skeptical:

in my environment they do not apply - I own all the machines involved

Do you know for 100% sure that you'll never ever ssh / telnet / netcat (even for debugging, maybe on http port 80 or so) to a machine outside of your security realm; or if you do then you'll remember to turn off this feature beforehand?


I (or we), as developer(s), have to think differently.

If we offer a run-time switch (visible config option, hidden config option, cmdline switch etc.) then users will find it, users will tell each other on forums to enable that option, and many will blindly enable it without properly considering the security implications. Security is defeated.

If it's a compile-time switch then some distros won't enable it (their users still complaining about the lack of copy-paste support), some other will perhaps enable (posing the security risk to all their users). Neither of which is good.

If end users who know it's safe for them need to recompile the package anyway, then you can go ahead and patch in OSC 52 support, it shouldn't be very hard (well, first check if someone has already done and shared that).

"Let's ship a feature for only those users whose setup meets certain security criteria" is in my opinion not an acceptable option for developers of terminal emulators, nor for developers of terminal-based apps. If people want to have this feature, it's the developer's job to ship a solution that can safely work for all users.

From my point of view, as a developer who contributes improvements, security cannot be optional, security must be mandatory.

Maybe we should just go ahead, design and implement our new protocol, and post feature requests against apps to see if it grains traction...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants