I followed all the instructions in your guide about session messenger and applied them to Signal. After that, I opened Signal in a disposable VM, sent some messages, changed some configurations, and downloaded some attachments. Then I shut down the disposable VM.
After starting Signal again in a new disposable VM, all of my changes were gone; nothing was there.
Signal was back to the state when I created its VM as disposable.
If I’m understanding you correctly, that’s the expected behavior. To have these changes persist you have to copy or sync specific files back to the disposable template.
You didn’t understand what I was asking for.
I wanted a way to ensure all changes in the ./config/Signal/ folder persist without copying files every time I open a disposable VM.
That’s why I asked to make Signal “persistent,” so changes are saved in its actual AppVM after each session in a disposable VM.
Rephrasing: I want the files in /.config/Signal to automatically sync back to the disposable template after each session in a disposable VM, without any user interaction.
Is that even possible?
It should be possible, but it goes beyond anything I’ve tried to date. There is at least one guide in this forum on using rsync in Qubes and unman created qubes-sync, but it hasn’t been updated since r4.1. Syncthing is another possibility.
Not an expert here, but…
For a disposable, everything it has when it boots is exactly unchanged next time it boots… I don’t think it can possibly get a writable /RW
Except maybe you can give it a block device, which it can mount, and then use yourself like a /rw, but without the convenience. Everything that follows may be wrong…
For example, a partition image file on another VM, as explained here: How to use block storage devices | Qubes OS
I never tried this.
Maybe bind-dirs will not be possible, so it would be necessary to mount it in fstab, and then bind mount its directories where they must be.
I would be interested to know what works. It seems a fun, useful, and maybe risky way to subvert the concept of a disposable qube!
I was looking for a concept similar to Tails’ persistent storage, where I can specify files or folders to remain persistent across reboots and retain changes during operations on disposable VMs.
However, it doesn’t seem possible now…
It could be possible but not without a lot of work…
So I’m asking it again: why not just a regular AppVM, used only to run Signal, where every file or link you open will be open in a disposable? If you really want to “clean” your VM you can do it on boot or shutdown too.
Could you elaborate on that? How can I do it—cleaning the VM on boot or shutdown, and opening every link and file in a disposable way?
Are you suggesting doing it manually, or is there another method?
On the cleaning part I was thinking of a script put in rc.local for startup, like something that backups the home folder, create a new one and copy the Signal folder in it again?
On shutdown, I don’t know, it must be related to systemd, and probably unreliable (imagine the VM crashes for any reason). A libxl hook could be more reliable but I had no luck with this and it could be too much work?
On opening file and links, follow this guide:
Off-topic(?): take a look at qubes-app-shutdown-idle, although it’s not what you’re looking for, it will give you the same feeling as a disposable that’s shutdowns when you close Signal.
The following github issue is relevant to the implementation of a disposable signal-desktop.
Also worth noting how the change came about…
What @parulin suggested—adding a script in rc.local for startup and opening all files in disposable qubes—meets my needs to some extent. The auto shutdown of idle VMs is a handy feature, and I believe it should be part of QubesOS by default.
However, I don’t understand how the links provided by @ephile are relevant to my issue. Storing encryption keys and other data in the GPG keychain was a long-awaited feature for Signal Messenger, but it doesn’t affect my problem. I don’t want to link a new Signal in a dispVM; I want to link Signal on a regular AppVM, let it sync with the primary device, create a keychain password for it, and then make that AppVM a disposable template.
This way, when I open Signal in a dispVM, I just need to enter the password for the keychain to start using Signal. The real problem arises afterward. While I’m not overly concerned about personal messages, sometimes I need to save something in ‘Note to Myself,’ and there are also group messages. Occasionally, a contact resets their Signal, and the keys are regenerated—all these need to be preserved across reboots. That’s why I need related files to be persistent.
I’ll wait for any more ideas in this regard; if not, I’ll mark @parulin’s post as the solution.
It’s relevant if one wants the dispVM to start with a clean state, or if one wants to migrate an existing Signal account. In your case, the dispVM will include the data in its initial state, along with anything else Signal modifies in the user’s home directory, which sounds like the simplest solution to meet your requirements.
Or leave it without any solution, which is more accurate?
Leaving Signal aside, is there any way to modify a file in a DispVM that is already present in a DispVM template and have the system preserve the changes?
The following thread has some good suggestions. If those don’t work, asking this question there may get more traction.
or the following thread, which is currently active: