Improve the way the UpdateVM setting is presented to users in qubes-vm-settings

[adrelanos]

Qubes OS version:

R4

Affected TemplateVMs:

dom0

---

Steps to reproduce the behavior:

open qubes-vm-settings

Expected behavior:

Should have UpdateVM setting.

Actual behavior:

Does not have UpdateVM setting.

General notes:

Cloning a TempalteVM is a natural step, even an encouraged one. The newly introduced burden in Qubes R4 that one has to edit dom0 configuration after cloning a template is a big usability issue.

NetVM being set to none for TemplateVMs (especially Whonix TemplateVMs) is very confusing for most users. (User question: "How shall I upgrade without a network connection.") Many users will think this is wrong and will manually set a NetVM.

Users who clone their whonix-gw / whonix-ws will very likely have a clearnet leak, will have them upgrades through clearnet rather than Tor which is clearly unexpected. (#3118) It is very non-obvious and difficult to learn that one has to edit dom0 /etc/qubes-rpc/policy/qubes.UpdatesProxy.

Therefore I suggest adding to qubes-vm-settings an UpdateVM setting below its NetVM setting.

I wouldn't call it UpdatesProxy rather than UpdateVM, because UpdateVM makes more sense for users.

---

Related issues:

#3118

[adrelanos]

Should this ticket have the qubes-manager tag?
Dunno if qubes-vm-settings is considered part of QVMM.
I think this is primarily a GUI rather than core issue.

[marmarta]

fixed and obsoleted by QubesOS/qubes-desktop-linux-manager#133

[adrelanos]

Will there be an UpdateVM setting (to configure UpdatesProxy) in QVMM?

[marmarek]

yup, see the second screenshot at https://github.com/marmarta/qubes-config-manager#updates

[adrelanos]

yup, see the second screenshot at https://github.com/marmarta/qubes-config-manager#updates

Screenshot https://github.com/marmarta/qubes-config-manager/raw/master/images/global_settings_updates_2.png is still a global setting.

This ticket is a feature request to make the UpdateVM (UpdatesProxy) for a Template configurable in the per VM (Template) settings.

For example in https://github.com/marmarta/qubes-config-manager/raw/master/images/new_qube_app.png under the Network tab there would be:

• Network connection: (exists already)
• UpdatesProxy: (feature request, this ticket)

This is because as it seems implemented now, it seems still very difficult for users to predict which Net Qube will be used for Templates (UpdateVM (UpdatesProxy))?

Configurations such as "update Whonix Templates through sys-whonix but update all other Templates through sys-firewall" would still be difficult, require manual qrexec config file editing?

Another use case is cloning a Whonix Template. Which UpdateVM would be used for the cloned Whonix Template and how would the user see this, change this?

[marmarta]

The thing is, there is no per-vm setting of "which update vm to use". There is only general policy. You can't really set it per-vm, not without meddling with multiple policy files.

[marmarek]

Configurations such as "update Whonix Templates through sys-whonix but update all other Templates through sys-firewall" would still be difficult, require manual qrexec config file editing?

This is actually what this settings tab do: you have separate update proxy setting for Whonix (qubes with whonix-updatevm tag), and default for every other template. See the very central part of the screenshot you linked.

And in fact, configuration like this is a reason to not put that into per-vm settings. Because then, you'd need to change it in several places (and likely miss some) to achieve this result.

Another use case is cloning a Whonix Template. Which UpdateVM would be used for the cloned Whonix Template and how would the user see this, change this?

Tags are preserved during cloning, so it will still use the one for whonix.

[adrelanos]

Please re-open.

Configurations such as "update Whonix Templates through sys-whonix but update all other Templates through sys-firewall" would still be difficult, require manual qrexec config file editing?

This is actually what this settings tab do: you have separate update proxy setting for Whonix (qubes with whonix-updatevm tag), and default for every other template. See the very central part of the screenshot you linked.

I think users trying to debug issues similar to #8490 are not looking there. Other things that users try is to create a clone of a Template (whonix-gateway-clone) and a new (or cloned) sys-whonix-2 and want the whonix-gateway-clone updates through sys-whonix-2.

By using QVMM create/clone template and qubes-vm-settings it's not obvious at all that there's a separate UpdatesProxy setting. Even if users previously saw Qubes OS Global Config -> Updates, they might not have understood it or not remember about it in that moment.

Hence, I have an idea...

And in fact, configuration like this is a reason to not put that into per-vm settings. Because then, you'd need to change it in several places (and likely miss some) to achieve this result.

I see your point.

So how about an "informaion-only setting" in qubes-vm-settings?

In qubes-vm-settings an UpdateVM setting below its NetVM setting. But make it information only. Meaning, it will be grayed out. It cannot be changed there. And add an I (info) symbol right next to it. A tooltip would explain that this setting can be found Qubes OS Global Config -> Updates.

[marmarta]

I like this info-only solution. (Patches welcome, I won't get to it any time soon probably and sadly)