wayland/clipboard: stop reading passwords?

[martinetd]

Background: I've started using wl-copy --paste-once recently, and it took me a while to figure out that it stopped working when mpv was running because mpv was reading my passwords.

So, for passwords specifically there's a thing with x-kde-passwordManagerHint -- if there's an offer with this mime type, mpv could ignore the update; it's probably not too hard to do, I might send a PR for it if it makes sense, and I'll be mostly happy...

But even for non-passwords I'm not sure I like the way this works, reading everything I could select (primary selection) or copy... One problem for example is that mpv will read data one chunk at a time and remember it all so I could just make a client streaming infinite data and crash mpv.
First, to make sure I understand why we're reading the clipboard on every update even if nothing uses it, I guess it's to avoid blocking whatever handled a key binding, as reading data from clipboard is easy to hang if the sender just doesn't send data when requested, so instead of e.g. hitting ctrl-v and then getting stuck only that background clipboard thread would get stuck and the previous data would still be available and all is well...?
I would have suggested only getting data if there's focus (or a lua script requesting clipboard if possible), but if there's no output we just can't tell if there's focus... I guess we could limit the buffer size we're reading in
get_selection_data() ? I'm frankly inclined to think I'd just prefer mpv to request data when hitting ctrl-v and sod it if the last offer came from a badly behaved client (perhaps with a timeout?)...
Or could the keybind trigger fetching data from background thread and have a callback from said thread handle adding to playlist or calling into lua?...

Anyway it's getting late for me and I'm losing focus; first thing first I'll open a PR with the x-kde-passwordthing in the next few days unless someone screams not to.

Thanks!

[na-na-hi]

So, for passwords specifically there's a thing with x-kde-passwordManagerHint -- if there's an offer with this mime type, mpv could ignore the update; it's probably not too hard to do, I might send a PR for it if it makes sense, and I'll be mostly happy...

I think the current mpv policy on wayland is to avoid compositor or application specific handlings like this.

so instead of e.g. hitting ctrl-v and then getting stuck only that background clipboard thread would get stuck and the previous data would still be available and all is well...?

This cannot be done because clipboard is accessed through properties and property access is always synchronous and happens in main player thread. Any delay in property access will cause the player to lock up. Async access to clipboard would require new commands.

I would have suggested only getting data if there's focus (or a lua script requesting clipboard if possible)

--clipboard-backends=vo does this and prevents mpv from reading clipboard when not in focus.

[martinetd]

Thanks for taking the time to answer!

I think the current mpv policy on wayland is to avoid compositor or application specific handlings like this.

This has x-kde-.. in the name but it's becoming a de-facto standard, e.g.

• wl-clipboard added wl-copy --sensitive ( bugaevc/wl-clipboard@e3c1b21 )
• fcitx5 "clipboard manager" module handles it ( https://github.com/fcitx/fcitx5/releases/tag/5.1.9 )
• from fcitx5's release note things like keepassxc also set it
• (I'd assume tools in KDE also handle it given the name...)

Given the merry mess that wayland is I assume that at some point someone will try to give this a more official name (... or even worse a new version of clipboard-related protocols), but I haven't seen anything about that, so I consider this to be a de facto standard for now -- at the very least this sounds more reasonable than a full rework of how the clipboard is handled e.g ↓

This cannot be done because clipboard is accessed through properties and property access is always synchronous and happens in main player thread. Any delay in property access will cause the player to lock up. Async access to clipboard would require new commands.

Sounds like it'd still be allowed to have the action in main thread kick in another thread to grab the content and modify the playlist after the action callback returned if someone wants to bother.

--clipboard-backends=vo does this and prevents mpv from reading clipboard when not in focus.

Thank you, I used that at first but I've made it so non-"privileged" programs cannot use ext-data-control-v1 anymore, so I guess I'm beating on a dead horse.
This question was mostly about raising awareness for me, if you (as in mpv contributors in general) are aware of the "problem" that sensitive data is being read and kept in memory (available in lua scripts!), then I'm happy with my workaround.

(If anyone cares, I asked for my compositor if it was possible to restrict such protocols natively in
YaLTeR/niri#1773 (reply in thread) - it wasn't so I'm doing unholy things with https://github.com/martinetd/create_wayland_security_context_v1 to replace the main wayland socket with a "restricted" one, and only start programs that need such protocols with access to the original "privileged" socket)