“effect” still needed to be changed to “affect” in that blog post
Anyway, I have tested Option#1 of generating a non-customized DisposableVM-Template which works.
So, you can remove the “untested” tag from the wiki here:
Option #1: Use a non-customized DisposableVM-Template. (untested) This template will use a stock image based on whonix-ws and will not preserve any changes that are made to it.
Re: “Adding shortcuts to applications menus”, which is also untested in Qubes 3.2, I have followed the steps up to this point:
Once the .desktop files have been created, they need to be added to your Applications menu. Use a text editor to edit the following file.
Note: There is NO xfce-applications.menu entry anywhere in the template. I have searched using find and ls to no avail. Using kwrite as above just creates a new (empty) file.
Surely Marek knows where this (.menu file) is stored for dispVM template in the Qubes architecture? After all, the entry for the original DispVM menu can be edited to replace Firefox with the Tor Browser entry instead via Alt F3 in dom0.
So where is it? Adding the additional .desktop entries should be simple enough. Maybe he can give us some pointers.
I have not attempted the menulibre option, as I don’t want to bork my menu as per other people’s recent experiences.
You mean dom0 right?
This is the reference I used for instructions: https://wiki.xfce.org/howto/customize-menu
Things to try:
sudo find / -name *.menu
- looks like default install location is
Instructions say to make a copy in
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: https://specifications.freedesktop.org/menu-spec/menu-spec-latest.html#paths. 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: https://github.com/QubesOS/qubes-desktop-linux-xfce4/blob/release3.2/garcon/garcon-0.2.0-qubes-menus.patch, 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.
- tb-updater needs to copy new TBB to
- set updateVM to
or better but less usable: create new disposable-serviceVM to handle updates & non-random clockVM; attach to netVM:
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?
- Don’t run
tb-updater-first-boot.servicein TemplateVM. (Already implemented.)
- Don’t run
- Don’t run
tb-updater-first-boot.servicein DispVM Template. How could being run inside DispVM Template be detected from within the
- Don’t run
- Copy from
/var/cache/tb-binaryto user home. (Already implemented.)
- Copy from
–> That would result in
whonix-ws-dvmbased DispVMs inheriting upgraded versions of Tor Browser if the
whonix-wsTemplateVM 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.
- Qubes R4: How to start the DispVM Template another time for reconfiguration? - https://groups.google.com/forum/#!topic/qubes-users/jdGs4aXA1xs
- Qubes R4: DispVM Template vs DispVM initial startup vs startup usability bug? - https://groups.google.com/forum/#!topic/qubes-users/8V4CzVqxCUk
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.
- https://phabricator.whonix.org/T726#14833 is resolved in Qubes-Whonix 14 after upgrades
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.)