Release signing key
If a warning sent you here
- Compare the fingerprint in the warning against the one above, character by character. Every character must match.
- If they match, the key is the right key, and the warning is about the file you downloaded rather than about the key. Follow the warning's own instructions — do not override it because the fingerprint checked out.
- If they do not match, stop. Do not continue the install and do not trust the download. Email security@intergenstudios.com with the warning text and where you obtained the media.
A subkey number instead of this one is normal
Verification tools usually report the signing subkey that made a particular signature rather than the primary key. Today that value is D7AA 641D 81AC D690 C5AD 865E 7276 E14D D888 6BFE. Seeing it is expected. Signing subkeys are replaced on a schedule; the primary fingerprint above does not change, which is why it is the value to compare.
What you can check, and what each check proves
1. That your download is the image this project published. Two steps: check the signature on the published checksum file, then compare your copy of the image against it.
gpg --import intergenos-release-key.asc gpg --verify intergenos-r001.iso.sha256.asc intergenos-r001.iso.sha256 sha256sum intergenos-r001.iso
1beeb90539bc1031ad135148f379e97a1830b835350f9c7924fd7b9fc3db07c7Proves: that the checksum file is the one this project signed with the key above, and that the image on your disk matches it — so the image you hold is the one the project published. The limit that remains: the signature covers the checksum file, not the image bytes directly. The comparison in the last step is what carries the guarantee across to the image, so both steps are needed — the hash comparison on its own is only a transfer check.
2. That the software you install is authentic. The package index is signed with the same key. With it already imported from the step above:
gpg --verify InterGenOS.db.sig InterGenOS.db
Proves: the package index was signed by the holder of this key, and no package listed in it has been substituted. This is the check that establishes authorship.
3. That a release tag is authentic. In a clone of the source repository, with the key imported:
git verify-tag R001
Proves: the release tag was signed by the holder of this key.
Reading the output honestly
A successful verification looks like this, and it includes a line that reads like a problem but is not one:
gpg: Signature made Sun 16 Aug 2026 08:30:16 PM CDT gpg: using RSA key D7AA641D81ACD690C5AD865E7276E14DD8886BFE gpg: Good signature from "InterGenOS Project Signing Key (primary) <intergenos-primary@intergenstudios.com>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner.
That warning is about your keyring, not about the signature. It appears because you have not personally certified this key as one you trust, which is the normal state after importing a key you just downloaded. It does not mean the signature failed.
Two things decide the outcome: the words Good signature, and the key shown matching the fingerprint at the top of this page. If you see BAD signature, or a fingerprint that does not match, treat the artifact as untrusted.
Check this fingerprint somewhere else as well
A fingerprint published in one place proves nothing if that one place can be tampered with. Confirm the same value in at least three independent locations before you rely on it:
- This page, served over TLS by the InterGenOS project.
- intergenstudios.com/signing-key — the same publication on the studio site.
- The public keyservers:
gpg --keyserver keys.openpgp.org --recv-keys 5597A3E0587B253006D0DD7B8C50826182083050, and the same command againsthkps://keyserver.ubuntu.com. - docs/signing-key.md in the source repository, alongside the armored key file committed next to it.
- The key itself, at repo.intergenos.org/keys/intergenos-release-key.asc, next to the signed checksum file at intergenos-r001.iso.sha256.asc.
If any two of them disagree, assume the network path you are using has been interfered with. Do not import the key, and write to security@intergenstudios.com.
Publishing the fingerprint in several places you can reach independently is what makes it possible to check this project rather than take its word for it.