If you get comfortable with git (and virtual consoles, was not even required for me), you can easily rewind any changes by non-root applications such as menulibre that are only writing into the home folder.
All in dom0
Seems like some
.desktop file is required in
qubes-dispvm-firefox.desktop is referenced in:
I guess these are the files to edit by emulating how its done with the two above files. A word of caution: I managed to loose my system settings Qubes start menu entry by just adding a new desktop file to
What if you
cp /etc/xdg/menus/xfce-applications.menu ~/.config/menus/ first?
That restored my system settings Qubes start menu entry.
DefaultMergeDirs. That may be a lead for investigation.
DefaultMergeDirs to me implies it may be possible to extend the start menu without having to directly edit
~/.config/menus/xfce-applications.menu (by editing some other file).
XFCE follows the freedesktop standard. The
DefaultDirs are explained here: Desktop Menu Specification. These Dirs specifiy locations to look for .menu (MergeDir), .directory (DirectoryDir), and .desktop (AppDir) files.
I decided to stop being an idiot and went to look for the Qubes .menu file. From this: qubes-desktop-linux-xfce4/garcon-0.2.0-qubes-menus.patch at release3.2 · QubesOS/qubes-desktop-linux-xfce4 · GitHub, it looks like Qubes is pulling in .menu files from some
applications.d directory. Best guess for location would be one of
$XDG_DATA_DIRS, so maybe
/usr/local/share/applications.d/. That must be where each VM has its own .menu file. If you can locate the DispVM-like.menu, then it should just be a matter of adding custom .desktop to the
Thanks to both of you. I’ll play around with this and see if I can work it out.
How timely… if anyone is looking to become an expert in Qubes appmenus… https://groups.google.com/d/msg/qubes-devel/nR_VRLX6FPc/JDoWwKkBDgAJ
We should test these Qubes instructions for DispVM customization and then replace the existing (untested) instructions we have for DispVM menu customization.
I presume everything is the same as below, except references for usr/share/applications is replaced by ~/.local/share/applications for Disp Whonix-Workstation VMs (?)
Adding arbitrary programs to Disposable VM Application Menu
For added convenience, arbitrary programs can be added to the Application Menu of the Disposable VM. In order to do that arbitrary.desktop file has to be created in /usr/share/applications in Dom0. That file will point to the desired program. Use following template when creating a .desktop file:
Exec=sh -c 'echo arbitrary | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red
Name=DispVM: Arbitrary Name
GenericName=DispVM: Arbitrary Generic Name
Next, the /etc/xdg/menus/applications-merged/qubes-dispvm.menu file has to be modified so that it points to our newly-created .desktop file.
Add arbitrary.desktop line to the block. The modified file should look like this:
qubes-dispvm-firefox.desktop qubes-dispvm-xterm.desktop arbitrary.desktop
After saving the changes our program should appear under the Disposable VM Applications menu.
For Qubes R4 there have been quite some changes that need catching up:
Things are “starting” to get confusing
inheritance (on create) persistence (on poweroff) TemplateVM n/a everything TemplateBasedVM /etc/skel/ to /home/ /rw/ (includes /home/ and bind-dirs) DispVM /home/ nothing
Conceptually, dispVM is now more flexible/convenient than before but potentially less anonymous since they are based on templateBasedVM and not templateVM - meaning there are more opportunities to configure them badly.
sys-whonix; disable update proxy in
//cc @marmarek Please have a look the post above mine.
It’s a nice table! @entr0py Perhaps add DispVM template or is it the same as TemplateBasedVM?
Could you please add the table to Whonix or Qubes wiki? (The latter would be better since it specific to Qubes, not Whonix. However having this table anywhere for reference would help a lot.)
When trying to start a DispVM for the first time, it actually starts the DispVM template such as
whonix-ws-dvm. After shut down, using the very same shortcut to start the DispVM, it starts an actual DispVM starting
Disp[...]. The user may be confusing the DispVM template for the actual DispVM since there is no graphical explanation what is happening. Is that right? If so, shall we open a usability bug?
How to start the DispVM Template (such as
whonix-ws-dvm) for a second or subsequent time?
It’s maybe not ideal to introduce
UpdateVM. That would hopefully only be an intermediary solution if anything. (As per this)
whonix-ws based DispVM act as UpdateVM? Does that even require development on the Whonix side? (UpdateVM might work out of the box? Qubes updates proxy likely not?)
Hm. Good question. Still trying to wrap my head around it.
Based on that, what about the following implementation?
tb-updater-first-boot.servicein TemplateVM. (Already implemented.)
tb-updater-first-boot.servicein DispVM Template. How could being run inside DispVM Template be detected from within the
/var/cache/tb-binaryto user home. (Already implemented.)
→ That would result in
whonix-ws-dvm based DispVMs inheriting upgraded versions of Tor Browser if the
tb-updater package in
whonix-ws TemplateVM gets upgraded. That would spare the user from having to run
whonix-ws-dvm, which really wouldn’t be great to require (one VM more to update, one more complication).
Awesome, in Qubes R4, we can have a
whonix-ws based disposable AppVM acting as UpdateVM as @marmarek pointed out. Sounds not too difficult, but I haven’t tried it yet.
In short: in Qubes-Whonix 14 after upgrades new AppVMs and DispVMs are created with a copy of the latest version of Tor Browser after
whonix-ws TemplateVM was upgraded.
tb-updater and /usr/bin/torbrowser will refuse to start in Qubes DVM Template. (Advanced users could overwrite the function easily using a config snippet but I doubt there is a use case.)
Major update of documentation for DispVMs for Qubes R4 with Qubes-Whonix 14.
Has still quite some
TODOs. Help welcome.
Bold changes. Lots of purges. If anything got missing in action it can be recovered from Outdated, Deprecated, Archived Whonix ™ Documentation. or from wiki history.