4.1 no longer allows copy and pasting to same VM

[tetrahedras]

In 4.0 and earlier, it was possible to copy (Ctrl-Shift-C) text from a given VM and then paste it back to the same VM with Ctrl-Shift-V.

With 4.1, this appears to be no longer possible. Pressing Ctrl-Shift-V on the origin VM no longer results in any action.

Because there are several clipboards in Linux, copying from and then pasting back to that VM was a useful way to work around issues related to these clipboards.

How do I re-enable pasting to the origin VM?

[Nurmagoz]

This is not a bug, the whole point of Ctrl-Shift-C & Ctrl-Shift-V is to transfer text from VM to VM.

If you want to copy/paste something within the VM itself just use Ctrl-C and Ctrl-V thats it.

[tzwcfq]

Well it'd be actually a handy feature sometimes to have two clipboards available in VM so you can copy two parts of a text from one place in document then scroll to a different part in document and paste text from both clipboards there.

[Nurmagoz]

you cant have 2 clipboards having different copies targeting one machine (at least in xfce), if you want to do that in qubes: Ctrl-Shift-C from VM1, Ctrl-Shift-V to VM2, Text A Ctrl-C from VM1, Text B Then you can Ctrl-Shift-C and -V again from VM2 to VM1 But i never encountered such need for this, And i dont think such feature gonna happen here. tzwcfq:

…

Well it'd be actually a handy feature sometimes to have two clipboards available in VM so you can copy two parts of a text from one place in document then scroll to a different part in document and paste text from both clipboards there.

[tzwcfq]

If you need to use another VM as a buffer it'll be impossible to use this "two clipboards feature" anymore from the usability point of view as you need to press Alt+Tab and Ctrl+Shift+C/V multiple times as well as from security point of view as you won't be copying your possibly confidential text to secure dom0 anymore but to another VM. And to keep VM only to use as clipboard buffer just doesn't make sense.
Since @tetrahedras said that it worked before then I guess the global clipboard function was reworked and due to the specifics of the implementation or there being some security issues the copy/paste from/to the same VM was unimplemented/disabled.
If it's not a problem from security point and it won't take a lot of resources to implement it then it'd be nice to have this feature again.

[andrewdavidwong]

This is not a bug, the whole point of Ctrl-Shift-C & Ctrl-Shift-V is to transfer text from VM to VM.

If you want to copy/paste something within the VM itself just use Ctrl-C and Ctrl-V thats it.

Disagree. Unless there's some specific reason to prohibit it, the source and destination should continue to be allowed to be the same qube. Sometimes users change their minds about the destination mid-copy/paste or forget that the destination app is actually in the same qube.

Besides, we haven't even established whether this was an intentional change or not. @marmarek, was it?

[DemiMarie]

Besides, we haven't even established whether this was an intentional change or not. @marmarek, was it?

I believe I was the last person to change this code significantly. I can make a patch, but it is not trivial, as disposable VM names can be reused.

[marmarek]

as disposable VM names can be reused.

I don't think it's in any way related to the issue discussed here.

In any case, qrexec itself doesn't support loopback connections. Clipboard paste from Linux to Linux is the only operation that uses qrexec policy but underneath isn't really a qrexec connection - that's why it worked previously. But now the policy handling got unified and it prevents such connections regardless of the specific service.

Proper solution is implementing #951.

[UndeadDevel]

Just ran into this as well. I want to be able to copy something to global clipboard, restart the VM I copied it from, and then copy it back to that VM (I'm using named DVMs for some of the stuff I do, that's why the newly started VM has the same name). To get more concrete, one of the use cases is that I want the VM to have more CPU cores or RAM, which can only take effect if I restart it. The workaround of copying to another VM is obviously less convenient, especially if I'm copying somewhat sensitive data.

That's why I'm petitioning for #951 to be reopened, as it was closed for EOL reasons, but this issue is still around in 4.1.

[UndeadDevel]

Technically, this bug does still occur in Q4.2, but can be considered a duplicate of #951.

[github-actions]

This issue has been closed as a "duplicate." This means that another issue exists that is very similar to or subsumes this one. If any useful information on this issue is not already present on the other issue, please add it in a comment on the other issue. Here are some common cases of duplicate issues:

• The other issue is closed. The other issue being closed does not prevent this issue from duplicating it. We will examine the closed issue and, if appropriate, reopen it.
• The other issue is for a different Qubes release. We usually maintain only one issue for all affected Qubes releases.
• The other issue is very old. The mere age of an issue is not, by itself, a relevant factor when determining duplicates.

By default, the newer issue will be closed in favor of the older issue. However, we make exceptions when we determine that it would be significantly more useful to keep the newer issue open instead of the older one.

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "duplicate" is not accurate, please leave a comment below saying so, and we will review this issue again. For more information, see How issues get closed.