consider adding RPC based unattended upgrades mechanism

[evq]

The problem you're addressing (if any)

currently afaict all updates are handled through vmupdate which involves injecting the agent into the running VM. the agent is installed in dom0 but contains code that is specific to each templatevm distribution. in the general case, this makes it slightly more difficult to add support for new distributions since changes need to be coordinated across dom0 and the new templatevm. with the qubes.InstallUpdatesGUI mechanism, it was previously easy for a new templatevm ( or end user ) to override the updates behavior.

The solution you'd like

consider adding an RPC based unattended upgrades mechanism, e.g. qubes.InstallUpdates. this could write it's logs to /var/log/qubes/qubes-update to conform to current expectations around the vmupdate agent.

this could simply be a fallback for distributions where the agent is unsupported or it could be the primary target whose default implementation simply launches the injected agent. the latter allows for potential end user customization.

The value to a user, and who that user might be

1. user of community templatevms which currently do not support updates

• currently updates appear to be supported for fedora, debian, and arch whereas gentoo, guix ( wip ), and nixos ( wip ) are not supported. adding an RPC based mechanism will make it easier to add support.

2. user / organization who wants to customize update behavior
   • user who installs nix package manager on debian and wants these to be updated in addition to their apt packages
   • user who has AUR packages installed via yay and wants those to be updated
   • an organization using QubesOS as a base for a secure workstation who has custom update needs ( e.g. software with a built-in updater, etc. )

Completion criteria checklist

(This section is for developer use only. Please do not modify it.)

[marmarek]

See https://github.com/QubesOS/qubes-issues/issues/7992#issuecomment-2344636061 for explanation why not.

[github-actions[bot]]

This issue has been closed as "declined." This means that the issue describes a legitimate bug (in the case of bug reports) or proposal (in the case of enhancements and tasks), and it is actionable, at least in principle. Nonetheless, it has been decided that no action will be taken on this issue. Here are some examples of reasons why an issue may be declined:

• No solution can be found.
• The proposed action is not possible.
• The proposed action would weaken security to an unacceptable degree.
• The proposed action would be too costly (in time, money, or other resources) relative to the benefits it would provide.
• The proposed action would make some things better while making other things worse, and the trade-off is not worthwhile.

These are just general examples. If the specific reason for this particular issue being declined has not already been provided, please feel free to leave a comment below asking for an explanation.

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "declined" is not accurate, please leave a comment below saying so, and the Qubes team will review this issue again. For more information, see How issues get closed.