I’m currently using Signal Messenger in whonix workstation based AppVM and would like to convert it into a disposable VM while ensuring that my settings, keys, and messages remain persistent across reboots.
Is this possible? If so, what would be the best approach to achieve this? Any guidance or recommended setup would be greatly appreciated.
The link you provided discusses making files in system directories persistent in an AppVM.
I’ve been using QubesOS for over a year, but I only recently started working with disposable VMs and am still getting a full grasp of the concept.
Because of this, I’m struggling to understand how making system files persistent in an AppVM relates to keeping user files persistent in a disposable VM.
I only want Signal messages, settings, and keys to remain persistent while keeping everything else disposable.
I came across a similar approach for Session Messenger in the community notes, which gave me the idea. Before that, I was using Signal Messenger in a regular AppVM—then I thought, why not give this a try?
I was hoping for a ready-made solution where I could just follow the steps and have everything work as expected. When @ephile mentioned that a community guide already exists on this topic, my hopes skyrocketed.
Now, it looks like I’ll have to figure it out myself using the disposable Session Messenger community guide as a reference. Well, at least it’ll be a good learning experience!
I’ve never tried this, but you can make a disposable template from your current Signal appvm, and run a disposable to see if it’s working. But, beware, I think you may lose some messages…
My apologies, I was referring to the following guide, but now that I look back at it I realize that I was conflating with the community guide I created for Session. Since session-desktop is a fork of signal-desktop, you should be able to combine the two guides in tandem.
I don’t understand why you want to use bind-dirs in your guide? And I don’t understand all the ˋrc.localˋ thing: why not putting it in the good location in the disposable template? And, instead, why don’t you just start Session/Signal for the first time in the disposable template?
You could do this, and it would work fine, it just depends on what you want your persistent state to be. With Session doing so would fix your Session ID to a single account. The guide allows for the possibility of using a single disposable template with multiple accounts. This flexibility is more valuable with Session because of the relative ease of creating accounts, which do not require a phone number.
If you try to put a file in it’s “proper home” in the disposable template it will not exist in the dispVM spawned by that template. Files placed under /rw will persist and /rw/config/rc.local can be used to place them in their proper place in the dispVM before they are needed. However, bind-dirs are specifically meant for this purpose, so that’s the preferred method in Qubes.
I’m trying to clarify this, because the template/disposable template/disposable names are not always clear and in order to check if my solution could work… I suspect that we’re not talking about the same thing. If I create a file in a disposable template, let’s say ˋ/home/user/testˋ, it will also exist in the disposable qube, right? Of course, it doesn’t work like this with a real template.
And thanks for your explanations about how Session works, I still don’t get the ID thing but now I know why So your Session guide may be overkill as for Signal?
I just edited the Session guide to use bind-dirs. So took the chance to read it over again. I think the following sentence answers your question above:
As I recall, this was the only way I was able to maintain access the config files, but if you already have an existing appVM for Session (or Signal), then this would not be an issue.
The guide actually sets up a persistent SessionID, so is directly relevant to creating a disposable Signal template. I have also set up disposable templates without a persistent Session ID…
This is one of those things that’s worth testing for oneself, to get used doing things the Qubes way. But yes, folders and files in /home, /usr/local, and /rw will persist.
I have a copy of the Whonix Workstation Template with FlatPak installed… From there I can create an App Qube and install the FlatPak Application (in this Case Signal) with --user Flag… Maybe not the most elegant solution but works for me and is updateable…
The issue here is not just the persistence of files. What I’m looking for is the persistence of changes in the files.
What @parulin suggested is to create a disposable template from the current Signal AppVm. This will work, but in this way, neither new messages nor the keys of users I add while using the disposable VM will be retained. Therefore, the entire Signal folder, which contains keys, configurations, and messages, needs to be persistent.
The same applies to files placed in the /home directory of the disposable template. The files will remain there, but changes made to those files during use in the disposable VM will not be retained.
Copying the updated db.sqlite file to the disposable template will preserve the newly downloaded messages. I’m not sure about the keys/contacts, which I left as a TBD item when I created a disposable template for Session. Please report back if you figure this part out.