-
-
Notifications
You must be signed in to change notification settings - Fork 802
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
feat: implement opt-in OSC52 clipboard querying #6239
base: main
Are you sure you want to change the base?
Conversation
Hi 39555, This works nicely! Especially nice that you made it work with the mux-server as well. (It might be worth Great work. |
"@loops, what do you mean by the config on the remote server? I thought WezTerm only reads the config from the local machine. Could you write a small guide? |
I’m experiencing a strange bug on windows both in the GUI and when using |
I've spend some time digging in. Unfortunately. This feature can't work on windows due to ConPTY. They implicitly filter this osc without any user notification.... Both Alacritty and Rio terminals implement this feature and it doesn't work on windows either. |
- add new config option `enable_osc52_clipboard_reading = false` - add a new trait function: `Clipboard::get_contents(&self, selection: ClipboardSelection, writer: Box<dyn ClipboardReader>)` The clipboard content is read asynchronously by providing a sender channel `Box<dyn ClipboardReader>` The sender `ClipboardReader` is a trait that requires the channel to be the `Send` + `Sync` + `Debug` (for the `MuxNotification` enum) along with the special hackery trait `ClipboardReaderBoxClone` that allows `Box<dyn ClipboardReader>)` to be `Clone`
Thank you for this! This feature was essential and previously missing in wezterm.
EDIT: I cannot reproduce it anymore. Please disregard the comment. I really appreciate your work on this feature — it has vastly improved my experience with wezterm! |
Thanks a lot! Is there a blocker for getting a review/merge? |
Wez currently has no bandwidth to work on Wezterm. Maybe someone else could review it and suggest improvements before Wez is ready |
sequences to monitor whatever you have on the clipboard, which may occasionally | ||
contain sensitive data. | ||
|
||
Setting clipboard data that contains escape sequences or malicious commands and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question, since I don't understand. Is this still valid even using ssh (encrypted tunnel)? How can an attacker inject harmful characters without already knowing how to access to the encrypted tunnel?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They probably can't, but OSC 52 is a way to access the local clipboard from a remote location. If it's not your server — for example a telnet multiplayer game or netcat ..
— those servers could easily access your personal data. I doubt they could execute anything, though, as the data is base64-encoded.
Co-authored-by: Len Trigg <[email protected]>
Co-authored-by: Len Trigg <[email protected]>
Closes: #2050
Hi Wez! This is my first time contribution to the project. I've implemented the missing osc52 clipboard reading command. The feature is disabled by default and can be enabled via the config option
config.enable_osc52_clipboard_reading = true
. I've also added the documentation with security notes and some tests related to osc52.The clipboard content is received asynchronously through a channel, which is passed as the second parameter in the
Clipboard::get_contents
function. For theTerminalState
it is theThreadedWriter
directly, for the mux client it is a tx-rx channel that than sends the pdu responce with the clipboard data back to the server and than to the server'sThreadedWriter
.The waiting of the clipboard data on the mux server side is a bit clunky wezterm-mux-server-impl/src/dispatch.rs
because there is no promise handling mechanism similar to what the client has so I left a mutable promise variable before the message loop and handled the response with
if Pdu::QueryClipboardResponce(..) =
before passing a pdu to the actual server's message handler. I would like to hear any idea how to improve it.I am open to any suggestions for naming, fixes and improvements.