How I keep a closer eye on updates:
-
Look at the date of
repomd.xmlin Index of /r4.0/current/dom0/fc25/repodata/. This indicates when the repo as a whole was last updated. -
Look at dates of packages at: Index of /r4.0/current/dom0/fc25/rpm/. But the dates can be misleading, as the packages are built weeks in advance. They are first uploaded to
current-testand after bake-in period are pushed tocurrent, but the package incurrentwill retain the date it was pushed tocurrent-test. But this will still indicate the latest version of a package and when it was first made available that one can locally verify against.
Those will show what has been published. This assumes the date on the server hosting the packages is correct…
…so to take the paranoia level up a notch, and get a more granular view, look into the updates-status GitHub repo issues. What we care about are issues with the r4.0-dom0-stable label: Issues · QubesOS/updates-status · GitHub
There you can see when a package is built, pushed to current-test and then subsequently pushed to current.
As an example:
-
repomd.xml has a date of 18-May-2021 on the yum site as of today (May 18 2021).
-
rpm-4.14.2.1-5.fc25.x86_64.rpm has a date of 05-May-2021 on the yum site.
-
rpm v4.14.2.1-5 (r4.0) · Issue #2420 · QubesOS/updates-status · GitHub shows rpm-4.14.2.1-5 was built May 5 2021 and uploaded to
current-testing -
The same issues shows “Package for dom0 was uploaded to stable repository” on May 18 after marmarek sent a PGP-signed comment indicating the package could be pushed to
r4.0 current, assuming the SHA256 hash matches. -
A
qubes-dom0-updatetoday has installed a new version ofrpmin dom0. -
rpm -qi rpmshows the Signature info which has date signed and key id:RSA/SHA256, Tue 04 May 2021 06:45:18 PM EDT, Key ID 1848792f9e2795e9 -
The last 8 digits in the key id show it’s a trusted key (according to rpm):
rpm -qi gpg-pubkey-9e2795e9|grep PackagershowsQubes OS Release 4 Signing Key -
The last command also spits out the PGP key itself where one can verify the key against other public sources.
Bottom line - nobody wants to go through all of that. Testing what is already in the upgrade process and providing feedback is still helpful.