Allow shortcut for multiple use of clipboard data #159
Conversation
alimirjamali
force-pushed
the
issue-6640-multipaste-sequence
branch
from
6198368 to
7a3baed
Compare
| show_error_message(g, "secure multi-paste: failed to update modification time of file " QUBES_CLIPBOARD_FILENAME); | ||
| } else { | ||
| metadata.cleared = false; | ||
| save_clipboard_metadata(&metadata); |
There was a problem hiding this comment.
This will be quite confusing IMO. Here, you save metadata as after paste operation (paste_action=1), but later this will use it as after copy operation for another paste. The confusion is especially about "vmname" field, as it no longer matches the source of the current clipboard content. As it's written right now, it incidentally works, because you gui-daemon still uses the separate "source" file for policy evaluation, but it's very easy to miss this subtle difference (for example if gui-daemon or something else would be modified to use metadata file for the source vm information when pasting).
Maybe for multipaste it should leave most of the metadata unchanged (just update xevent_timestamp)? Or do not reuse "vmname" field for the name where the clipboard was pasted and instead add a new field for that (used also for paste+wipe)? The latter will potentially allow even more informative notification, as you'll have both source and target name at the same time.
As for copy_action / paste_action fields, I'm not sure how multi-paste should handle them. One of the options is to set both to true in this case. But I guess if properly documented, copy_action=false, paste_action=true may also work (together with cleared=false) may also work. Or even change this to a single "last_action" field?
Anyway, it would be good to write down somewhere (extend QubesOS/qubes-doc#1434? or a comment in xside.h?) all possible states, and what values different fields may have at that time and what do they mean. And also specify which fields may be missing and how to interpret it (see below). IIUC there are the following states:
- clipboard is empty, never used (file absent)
- after copy
- after multipaste, further paste possible
- after paste&wipe, again empty
- after copy, but cleared automatically without pasting (only after Clear global clipboard after specified seconds #158)
- after multipaste, but cleared after timeout (only after Clear global clipboard after specified seconds #158)
Right now I see for example that copy made by gui-daemon and by qui-clipboard widgets result in a different metadata files (widget doesn't set "oversized_request"). This may be okay if we have documentation what that means (in this case, that it should be interpreted as oversized_request=false).
fixes: QubesOS/qubes-issues#6640