How does one review updates / packages before updating?

User Support General
1

Hi Qubeheads,

Eternal lurker of the project and forums (for years) but only recently turned fanatical qubehead myself.

I am still getting to know the lay of the land, salt (and hoping ansible support soon) though I am a little familiar with both so really looking forward to qubes API/library to programmatically deploy disposable lightweight qubes and other such fun stuff. Also keen in getting around to test podman/docker and full virtual network maze deploys complete with air-gapped/networkless vaults inside a laptop :wink:

For now my most pressing questions are:

  1. Does 4.3rc1 classify as a testing release? That is - does our update cycle include frequent ‘testing’ updates and repos?

  2. Where is the best official source (github? forum? website? mailing lists?) to check when new package candidates have been published and ready for us to install? For verification/validation in case someone on the insecure intermediate network MITM’s a fake mirror and pushes ready2pwn updates to my qubes update manager? I am getting a very high frequency of updates (almost daily) so am looking for a second channel (something other than the qubes update manager) to validate the updates notifications I am receiving are in deed legitimate, official updates.

  3. Is there a method to show what packages are being updated prior to installing them? At least that way I can gauge risk better. and make informed decision about what to install and when. AI-GPTs told me that the packages flagged for update should be visible right in the qubes updater itself, but I could not for the life of me find an option or where to click to reveal that information. I also scoured the official documentation, as well as the forums a few times without finding a clear answer on how to achieve this. If it is possible to do via cmd line (apt/dnf) that is even better, but as it stands I could not even achieve this with the qubes-vm-update command (doing --list or something similar). This would be useful information to include in the Updating Guide.

If anyone is able to point me in the right direction it would be greatly appreciated.

Thanks and love your work.

2

ad3. As for reviewing updates, you may go to every template, run terminal and invoke

sudo dnf update

if there’s something to update it will be listed and you will have chance to agree to that transaction or cancel it whole.

PS: for debian it would be sudo apt update IIRC (14yr last time used debian based distro, and I’ve preferred 'apt-get`)

1 Like
3

You can use CLI tools.
In dom0:

sudo qubes-dom0-update --action=check-update

In Fedora template:

sudo dnf check-update

In Debian template:

sudo apt update && sudo apt list --upgradable
3 Likes
4

Hi. And welcome

The answer is yes. But according to some of core developers, the rc2 (yes, we had rc2) is deployed to some of their customers already. And the current updates are only bug fixes. New features are not currently accepted for r4.3

The official source is qubes-udpate repository on Github and its issues. I publish a weekly review newsletter and list the new (testing) updates which would eventually land in stable. You could find it if you search the forum.

Also please consider many updates would be from upstream (Fedora, Debian) rather than Qubes.

We have qubes-vm-update --dry-run for updating vms and sudo qubes-dom0-update --assumeno. You could run hem in dom0 which will just print list of packages available for update.

2 Likes
5

That are two different topics. The updates for dom0 are in the resposibility of the qubes team. The updates for the VMs are (with some exceptions) in the domain of the maintainer of the distributions like fedora, debian or whonix, you have to decide, how far you trust them also (additional to trusting the qubes maintainers).
All updates (these for dom0 and these for the distributions also) are signed with the package keys of the maintainers, so the “bad guys” have to obtain these keys without getting detected by the maintainers.

1 Like
6

Thank you for the clarification. I think I have the hang of it now: I check on dom0, then I check on the individual domUs flagged for updates using said qube’s package manager for greater detail.

With regards to dev keys - that is assuming the dev or dev’s key is compromised. It is statistically more probable an end-user (aka- me!) or intermediate third-party is compromised.

Without even diving into how many distros do not use HTTPS for updates by default, or that tor updates are not using HTTPS by default, and the fact there are known tor attacks (not to mention likely 0days), let us crack open the “key has been signed so it should be OK” confirmation bias, so as to explain why I personally wanted an official second channel to validate/confirm updates were legitimate…

Network-layer subversion: Even before reaching an update mirror, attackers can silently redirect traffic. Common methods include DNS poisoning, ARP spoofing on a LAN, BGP hijacking on the wider Internet, or transparent proxy injection by ISPs and compromised routers. Wireless attacks expand this risk, with tactics such as evil twin Wi-Fi access points, SSL-stripping downgrade attacks, IMSI catchers, or even decommissioned telecom equipment reused by malicious actors. While HTTPS is designed to protect users, hundreds of certificate authorities and enterprise proxies are globally trusted, so a single mis-issued or abused certificate can make a malicious connection look valid to both the system and the user.

Infrastructure and supply chain compromise: Even if the path is clean, update infrastructure run by third parties can be tampered with. Mirrors and CDNs are attractive targets because a poisoned mirror can distribute malicious binaries at scale. Recent incidents in the npm ecosystem show how compromised maintainer accounts and worm-style campaigns can push tainted updates that appear legitimate, including the recent “Shai-Hulud” attack that hijacked 180+ packages and spread via stolen tokens and CI workflows underscoring the risk from intermediate services one does not directly operate. Attackers also exploit fallback behaviors, such as forced HTTP fetches that enable SSL stripping. Outdated routers, BIOS, and firmware with known or hidden backdoors further widen insertion points before the code ever reaches the endpoint.

Endpoint and ecosystem exploitation: Attackers increasingly bypass HTTPS by going after endpoints. Commercial spyware, state-grade malware, and leaked surveillance tools can compromise a device directly, manipulate trust stores, capture plaintext, or alter update flows in the operating system. Once the endpoint is undermined, even correctly signed updates can be replaced, blocked, or injected with backdoors. The core mistake is assuming a secure protocol or a developer key alone guarantees integrity. In practice, the attack surface spans the full trust ecosystem from local networks to third-party infrastructure to the device itself, and weaknesses at any layer can be exploited.

Even if we trust the devs and the mathematics/crypto - we are still ultimately building digital empires atop the shifting sand dunes of malleable silicon. The recent global tensions and cyberwarfare hunting season certainly do not make the situation any better. Not everybody can afford to or wants to implicitly trust their ISP or government’s infrastructure, when even they are getting pwned on a regular basis globally.