A checksum does not say who made the file
Checking the SHA-256 proves the download arrived intact. It does not prove who published the file — and that is a different question.
Almost every Linux installation guide ends the same way: download the image, check the SHA-256, carry on. It is a good habit, and we ask for it too. But it answers a narrower question than it appears to.
What a checksum proves
That the file on your disk is identical to the one that was published. It catches a corrupted download, a failing USB stick, an interrupted transfer. That is worth something, and not a little.
What it does not prove
Who published it. Look closely: you compare the file's hash against the hash printed on the same page you downloaded from. If someone replaced the image, they would publish the new hash alongside it — and your check would pass. You would have successfully verified a tampered file.
This is not hypothetical. It has happened to serious projects, from a compromised mirror to a breached download page.
Signatures are what answer it
A cryptographic signature does not say "this file is intact". It says "this file was signed by whoever holds the CapivaraOS private key". And that key is not on the download server. It is not on any connected build machine. It stays offline.
That changes things: a compromised server can at most serve files your system will refuse, because there is no way to sign them.
How to check, in practice
The public key already ships with the system. You compare its fingerprint against the one we publish:
gpg --show-keys --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-capivaraos-herdIt must read exactly this:
C852 6722 0A81 18C9 864F 0648 BE5B 82AD C8A2 85C0If it does not match, stop. A different key means the system is trusting someone who is not us.
One catch worth knowing
The update repository is signed too, and the system requires that
signature. But if you test it with dnf makecache, you will
be misled: on dnf5 it only warns when metadata is badly
signed, and still finishes saying all is well. The transaction is what
actually refuses it. To test, use dnf check-update.
Why we are writing this
Because "trust us" is not an argument. That is why we publish the fingerprint in full, explain where the private key lives, and document every command: so you can hold us to it.
The full walkthrough is in the security documentation, and what the system guarantees — with the command that confirms each claim — is in the Trust Center.