The code from below is given for qubes-manager, but can be used analogously for the other packages.
I unpacked the packages from the repository (in some fedora vm as well as in a debian like os running on independent real hardware) as well as the local packages (dom0) via:
mkdir qubes-core
cd qubes-core
rpm2cpio ../qubes-manager-4.3.23-1.fc41.noarch.rpm | cpio -idmv
The number of files in the corresponding qubes-manager directories are the same:
I did the same without “-type f” and compared the error output. The same.
But I found no explanation for differing packages, local compared to the repository, on the internet. Everything says, that the packages should be the same. And what drives me crazy is, that I could not find the local packages on any remote repository. This is a fact. The local files are exactly 3600 bytes smaller than the remote ones.
and downloaded qubes-manager-4.3.23-1.fc41.noarch.rpm to check for size and sha256-hash. The files are all the same and not the 3600 byte smaller version.
I’m running out of ideas. Is qubes altering the packages when updating, e.g., unpacking the packages, verifying and then rebuilding them again? In my opinion, this would make no sense.
Qubes OS recently updated my dom0. And just for fun, I compared the downloaded packages with the packages in the repository. I found some issues, the sha256-digest differ and the file size is exactly 3600 bytes smaller for each package locally compared to the remote files. However, everything else seems fine.
I found no explanation for that fact yet and are running out of ideas. This is not bugging me anymore, it is not making me crazy anymore, it really drives me nuts! I already opened a thread, where you can find the stuff I already did. However, the place is badly chosen (or the topic is uninteresting or I am too impatient) so that almost nobody looked at it.
I hope it has simple explanation, and I hope information about this behavior is easy to find, when you know the correct keyword. I hope, I am only a stupid, paranoid fool.
Yes. Packages arrive in dom0 via /etc/qubes-rpc/qubes.ReceiveUpdates, which passes each package through rpmcanon from qubes-rpm-oxide to canonicalize it:
I think the idea is to have some modern Rust code defang the package file before it is passed to the relatively complex rpm legacy codebase for inline signature validation. See the end of the Summary section of QSB-067.
thank you for your answer. That calms me down for today. I will go into detail in the next days. You gave enough hints.
Is there a way to canonicalize an rpm package manually? For testing. Like a command line call that uses qubes-rpm-oxide?
Moreover, I think this information is missing in:
(maybe I missed it?)
It would be good, to add or make clear, that the rpm-packages, that end up in /var/lib/qubes/updates/rpm/-folder might look different (size) than the originals from the repository. Actually, I would prefer the canonicalization being done in the background so that the original rpm is saved in the update folder. But I guess Qubes OS has it’s reasons to do it this way.
Yes, you can install the qubes-rpm-oxide package containing rpmcanon in a VM('s template) too. Although I don’t know if its canonicalized output there is necessarily identical to that in dom0.
Should be fine to just run it in dom0 though. After all, that’s what it’s for.
!