Global clipboard is very good for security but current implementation is very inconvenient. Example to copy from a web browser in one domain to a terminal in another domain.
Select text and press Ctrl+C. Make sure you don’t press Ctrl+Shift+C, the combination you use to copy in a terminal, this opens the web inspector. As a consequence of habit I sometimes do this.
Use the Win+Shift+C to copy to global clipboard.
Select the the terminal window. Press Win+Shift+V to paste to terminal domain.
Press Ctrl+Shift+V to paste in terminal. Make sure you don’t press Ctrl+C, this combination closes the active running program, this is bad if a CLI program is running and you want to paste some input. This has also happened to me a couple of times.
I personally use Win+C and Win+V for global clipboard to make things a little easier but it is still error prone. Suggestions:
Have the global clipboard run in parallel with the domain clipboards. Skip the step to copy to domain clipboard and allow direct copy to global clipboard by selecting text and directly use Win+C to copy to global clipboard. When you paste the global clipboard in another domain use Win+V to directly paste from global clipboard.
Allow pasting multiple times from global clipboard. If I need to copy from one domain to multiple domains it becomes very tedious… Achieve this by using a keepassxc style timer for global clipboard storage. After 10-15 seconds wipe the contents of global clipboard.
Integrate global clipboard copy/paste in dropdown menu’s. This probably isn’t technically feasible but I just thought to throw this in.
In the tray icon for the global clipboard add option to copy and paste to global clipboard. This is useful if you use the mouse a lot, no need to touch the keyboard, do all operations from tray icon.
You can automate this yourself with a script bound to a key
Sounds like a nice configuration option.
This won’t work because you either need to allow domains to grab stuff from global clipboard without asking (which is insecure) or make them ask you in a dialog every time (which I assume would topple any benefit you might expect from this)
You may be able to do similar thing with a script and a launcher in a panel. You might even use the same scripts from point 1. This is more of a hack though.
(new to QubesOS)
I also share the opinion that those shortcuts were not well-thought about.
And I have a bad time changing them.
This command qvm-features dom0 gui-default-secure-copy-sequence 'Mod4-shift-c' does not seem to work.
[edit]
In order to copy from a terminal you need to press ctrl+shift+c which will be trapped by QubesOS leading to not copying the target text in the terminal.
But what matters the most is that option to change it should absolutely be there, IK there’s a GUI that lets you do that, but I use a minimal tiling WM and I need the CLI way of doing it.
This command works for me (of course after start a new disposable). Is it an exact copy of the input you entered in dom0?
You have other shortcuts to copy-paste from terminal, like Ctrl+Insert and Shift+Insert. At first, I ignored them but now I believe it is better to rely on standard shortcuts instead of customizing them.
Yes, I did run exactly that command. I’ve ran it in a Dom0 terminal and tried changing Mod4 with other modifiers in case there’s a conflict with existing keybindings, and it did not work.
[Start-Edit]
Although Mod4+shift+c still does not copy to the global clipboard, I can now use ctrl+shift+c in Dom0’s Terminals but not in a disposable terminal for some reason.
[End-Edit]
I’ve just tried launching a disposable qube right now (qvm-run --dispvm default-dvm xterm) as you said (if I understood you correctly), IDK what that supposed to do, but it did not work.
And I don’t have an insert button in my keyboard (I could create one using Kanata, but let me give this initial approach more tries). Also, it seems like ctrl+shift+v is a more popular standard than ctrl+insert (or maybe I’v been exposed to one-sided content).
I did not try this before installing i3 (sudo qubes-dom0-update i3 i3-settings-qubes), maybe installing i3 did screw up something?
I’m getting the vibes (not from this forum topic but overall) that QubesOS is not meant for my way of doing things, cuz I tend to customize, automate and make reproducible and keyboard-centric everything, and it seems like QubesOS is meant to be ran as is, if I’m not mistaken.
I’m also planing to install sxhkd, dmenu and kanata immediately after configuring i3 and a lot more customisations that did not come to my mind right now.
If you want to get this to work, open a new topic about your issue maybe? I asked you to do that to check that a qube has been (re)started after the qvm-feature command. But now I’m wondering if preloaded disposable could interfer.
Okay, I understand and I didn’t mean that ctrl+shift+v is uncommon.
I don’t think so. I gave you my opinion but others here rely on heavy customizations.
I think I could be classified as one of the “others” . I’d say that it’s absolutely possible to customize a lot of things in Qubes and make it keyboard-driven (especially with i3), and automation’s not too difficult with Ansible. It will be more difficult than a traditional Linux distro, but it’s absolutely possible.
I think QubesOS prioritizes GUI over CLI, perhaps it’s right move since most people use GUI.
For instance, in the same topic, you can type whatever in the argument that is supposed take a keybinding in qvm-features dom0 gui-default-secure-copy-sequence 'sequence-here' and the command won’t give you any feedback as to whether that syntax is allowed or not, nor if the operation was succfull or not.
You’re of course right that the key sequence should go through a validation step. Qubes could benefit from more user/developer contribution, I think is how you should understand that. There is so much low-hanging QoL that could be done but hasn’t been done because of limited available engineering time- my impression.
I don’t feel it’s a GUI-centric OS but I understand seeing it that way given your experience so far. In the beginning, configuring the system and learning the ropes, you do spend a lot of time poking around the GUI tools. But then if it becomes your daily OS and you come to understand the patterns and systems that work together to make it go, also the common-case quirks, you naturally transition to the CLI tools as those are what you need for real orchestration and reproducibility. Qubes markets its security as its competitive advantage, but lab-on-a-workstation is the co-equal killer feature, and it’s impractical with the GUI tools.
. I’d say that it’s absolutely possible to customize a lot of things in Qubes and make it keyboard-driven (especially with