Related: Update check without sys-whonix - #20 by gabaz
Seems I am not the only to have asked.
Coming back from general Tor discussion to OP’s question:
I don’t quite understand, why it would make sense to possibly have two different internet routes to update Qubes software - one is the AppVM qube’s netVM, the other one is the global update proxy. What has the AppVM to do with updates? Updates only persist in the template.
Are there historical reasons for this decision? In my opinion this is disadvantageous from security, privacy and maintainance perspective due to leak potential, as illustrated. This model is also harder to understand for users, which need to be aware of conditions, under which one or the other route is taken. (There definitely is some room for community to contribute better documentation, too.)
What about this idea:
An AppVM qube A with parent template T should just trigger an update check request via qrexec (default: 5 minutes after qube startup), it should not consult its own NetVM. dom0 then starts T in order to actually do the update check. T is fully responsible for its update source/network. Per default it just takes the (global) Qubes update proxy, as templates usually don’t have NetVMs assigned.
Advantages:
- Unambigious update channel, easy to understand
- Get automatic update checks for templates of offline qubes as well.
- Update traffic network source (check + download) can be configured by single global setting under Updates → Update proxy → Default update proxy , e.g.
sys-whonixfor Tor updates
Would be curious, how much effort this change would require.