Qubes DispVM technical discussion

Qubes-Whonix
58

//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.)

Questions:

  • 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 sys-whonix-dispVM as UpdateVM. That would hopefully only be an intermediary solution if anything. (As per this)

Could a 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.

Related:

Based on that, what about the following implementation?

    1. Don’t run tb-updater-first-boot.service in TemplateVM. (Already implemented.)
    1. Don’t run tb-updater-first-boot.service in DispVM Template. How could being run inside DispVM Template be detected from within the first-boot-home-population script? @marmarek
    1. Copy from /var/cache/tb-binary to 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 tb-updater inside whonix-ws-dvm, which really wouldn’t be great to require (one VM more to update, one more complication).

1 Like