The (Updating Qubes OS | Qubes OS) page recommends against using qubes-dom0-update to update packages of dom0.
What are some possible risks for directly running sudo qubes-dom0-update rpm instead of using the “Qubes updater”?
I think there is no risk, but you may miss some changes to the system.
If you use the “Qubes updater” you are using Salt and the Qubes team use thar to make some security fixes.
Just run “Qubes Update” afterwards.
(At least that is what I think 
)
Upgrading dom0 with “qubes update” works for me now.
The current state of dom0 updates seems to be:
sudo qubes-dom0-updates doesn’t have the security benefits behind the GUI Qubes Updater, which uses the Salt version of this command. The main concern is with the Qubes repo metadata (correct if wrong), which isn’t verified due to some configuration issues. This would allow an attacker to block (but not modify) a package from being updated. A fix is being worked on and @adw is currently working on an announcement for this.
The Salt version of dom0 update has a critical issue that might be exploitable, since a bug in Salt leads to updates returning "OK"s even when it fails (e.g. ethernet cable unplugged).
So there are issues in both the Salt and the regular CLI versions of dom0 updates. The latter might actually be more severe (I think), but Salt provides the additional security checks, so it might be the lesser of two evils.
Either way, I think the case could be made for a website that lists dates on which dom0 packages were updated, sorted by date (so like a calendar) where cautious users get an easy resource to check if they suspect anything is off. Just another (low-cost) layer of protections, like an invisible pocket protector.
As usual, I’m not technical so take my words with a grain of salt (no pun intended). Also, is there a way to make a signature that’s added to every post I make? That thing kids in old-timey forums use to decorate their posts with flashy banners to show off.
For now, I’m just running both: qubesctl (Salt / Qubes Updater) first in case it does any Salty things, then the old qubes-dom0-update in case the first one missed anything.
I understand why you want this, but I believe it would be the wrong solution to the problem. Instead, the entire update system should be set up in such a way that you don’t feel the need to manually double-check its work. The fact that a user feels the need to make sure that the system is doing its job is a sign that there is something wrong with the system (or possibly with the user’s expectation). The solution is to fix that problem (or realign the user’s expectations), not turn the user into a micromanager of mundane machine monotony. 
@deeplow might know the answer to this.
1 Like
Hello there,
Completely agree.
I was thinking also about a feature proposition: not allowing a specific software to run if it has a known vulnerability and is not patched. Simple as that. So the availability can be sacrificed in favor of security, if needed.
I would be curious to know the developers opinion about Salt - is it in your eyes “a great tool”, or it would be more correct to describe it as “the only flexible enough solution able to do the job, being not that bad from security perspective”? Or something else? I was skimming recently the following interesting article: Unix Configuration Management Tools (short: Attempts to create a new JCL for Unix are OK. But pretentions that they change the current situation to the better are open to review. Is the King naked ?) .
Best,
Ivan
And what if i run updates through the Qubes Manager? Is it equivalent with the qubes updater or with the cli version?
This sounds hard to do and would most likely be a completely separate software project in itself.
Unfortunately, that’s a weird third in-between method. It does more than just qubes-dom0-update but is not exactly the same as the Qubes Update tool. I’m strongly in favor of phasing it out, as it seems quite confusing and unnecessary to have this third method.
I thought the Qubes Manager was just for updating domUs. There’s a way to update dom0 via the manager?
The “update” button is enabled for dom0, so I’d assume so. I don’t use it, so I don’t know. Anyway, I only mentioned dom0 specifically because that was the topic of conversation. My statement applies equally to updating TemplateVMs and StandaloneVMs. Just substitute whatever the direct update command is (e.g., dnf update).
I tested the Qubes Manager dom0 update by right-clicking and selecting Update qube. No CLI or GUI appears, but the update runs in the background. I confirmed this by then trying to use sudo qubes-dom-update, which returns the message:
Existing lock /var/tmp/yum-user-RGegpV/x86_64/4.0/yum.pid: another copy is running as pid xxxx.
Another app is currently holding the yum lock; waiting for it to exit...
The other application is: yum
But this begs the question–when using this method to update, how do you confirm what updates to install or see what has been installed?
No idea. Seems like another reason to dislike this weird third method. 
1 Like
I like how the update methods are being overhauled and unified, but I worry that Qubes might become too dependent on Salt. It’s not really that risky, since the CLI methods are still around and can act as a fall-back, but non-CLI users might have trouble (especially updating individual templates) if some Salt bug gets introduced in the future and shuts down updates (the Salt updating reporting bug isn’t inspiring confidence).
That, and I seem to remember Salt getting acquired recently.
1 Like
Qubes isn’t dependent on Salt - it’s just a useful tool in Qubes.
If there are Salt bugs we should fix them. In this case, I think that
the underlying fault is with dnf. Wherever, we should fix that upstream,
and patch in Qubes.
Salt is an open source project. It has not been acquired.
Saltstack is a private company that promotes and contributes to Salt. It
has been acquired by VMware.
I hope you get to the bottom of this. I’ve been antsy about updates since I started really using Qubes and this whole episode (starting with QSB-067) hasn’t helped. My memory about Salt’s acquisition was fuzzy, but it isn’t great that severe vulnerabilities seem to be popping up more and more in VMware products:
By the way, I had no idea you are on the Qubes Team. I just thought you were a really enthusiastic contributor. Hope you get your Qubes Network Viewer integrated into a future release somehow.