challenge · verify & rebuild

Anyone can check.
No one has to trust.

Every Odyssey package publishes a signed hash in a public manifest. You can confirm a package matches it in seconds — or, if you want to go all the way, rebuild it from source and prove the hash is reproducible, then publish your own signed result for others to see.

This page explains both paths. The tool is one script, odyssey-challenge, public on Forgejo.

01 · THE IDEA

A signed manifest of hashes

When a package is built, its SHA-256 is recorded in a single manifest, odyssey-challenge.json, served next to the packages. That manifest is signed with the maintainer's cosign key and logged in Sigstore's public Rekor transparency log — the same machinery that signs every package.

Because the manifest is signed, no one can rewrite it on the server to match a tampered package: the signature would break. Because each build is reproducible, rebuilding a package from its public recipe yields the exact same hash — bit for bit. Those two facts are what make the rest of this page possible.

The manifest lives here:

https://repo.odysseylinux.org/odyssey-repo/x86_64/odyssey-challenge.json
https://repo.odysseylinux.org/odyssey-repo/x86_64/odyssey-challenge.json.cosign.bundle

FOR EVERYONE

Verify

Confirm a package is exactly what the maintainer signed. Seconds, no build tools.

how to verify →

FOR REBUILDERS

Rebuild & attest

Rebuild from source, prove the hash, and publish your own signed attestation.

how to rebuild →

02 · GET THE TOOL

The script and the key

Download odyssey-challenge from Forgejo and make it executable:

curl -LO https://code.odysseylinux.org/nobody/odyssey-challenge/raw/branch/main/odyssey-challenge
chmod +x odyssey-challenge

You also need the maintainer's public key. Get it from a source independent of the package repo — the keys repository — so that no single server can hand you both a forged manifest and a matching key:

git clone https://code.odysseylinux.org/nobody/odyssey-keys

The file you want is cosign.pub. Verifying a manifest with a key fetched from the same place that served the manifest would prove nothing — the independence of the key is the whole point.

03 · VERIFY · FOR EVERYONE

Check a package matches

One command downloads the package and the signed manifest, checks the manifest signature, then compares hashes:

./odyssey-challenge verify PACKAGE --pubkey cosign.pub
It fetches the manifest and its signature bundle from the repo.
It verifies the manifest signature against your independently-obtained key. If that fails, it stops — a tampered manifest is never trusted.
It reads the expected hash for your package, downloads the package, and computes its actual SHA-256.
It compares the two.

THE RESULT

VERIFIED — the package is exactly what the maintainer signed and published.
MISMATCH — the package differs from the signed hash. Do not install it; report it.

Already have the .xbps file locally? Check it without re-downloading:

./odyssey-challenge verify PACKAGE --file ./PACKAGE.xbps --pubkey cosign.pub

04 · REBUILD & ATTEST · FOR REBUILDERS

Prove it from source — and vouch for it

Verifying confirms you received what the maintainer signed. Rebuilding goes further: it confirms that what the maintainer signed is honestly built from the public recipe — that nothing was slipped in between source and binary. This is the part that holds even an anonymous maintainer accountable.

ONE-TIME SETUP

You need a checked-out void-packages (with xbps-src) and your own cosign key — never the maintainer's. Generate one:

cosign generate-key-pair   # creates cosign.key (private) + cosign.pub

Keep cosign.key private; publish cosign.pub so others can verify your attestations.

REBUILD

Check out the recipe revision matching the manifest, then:

./odyssey-challenge rebuild PACKAGE \
    --rebuilder YOUR_HANDLE \
    --pubkey maintainer-cosign.pub
It verifies the maintainer's signed manifest (same independent-key check as above).
It checks your local recipe is at the same version and revision the manifest declares.
It rebuilds the package with xbps-src and computes the resulting hash.
It compares your hash to the manifest, then writes a signed attestation of your result.
WHAT YOU PRODUCE

Your own signed attestation

The command writes attestation-YOUR_HANDLE-PACKAGE.json and a .cosign.bundle, signed with your key. It records both hashes — the manifest's and your rebuild's — and whether they matched. A match says "I independently reproduced this." A mismatch is just as public and just as signed — it can't be hidden.

Publish both files anywhere. Others verify your attestation with your public key, exactly as they verify the maintainer's manifest. The maintainer never touches it, and cannot alter or remove it.

05 · TRUST MODEL

Attestations stand side by side

The manifest is the maintainer's own signed statement. Rebuilder attestations are separate files, each signed by its own author — they are never written into the maintainer's manifest. There is no shared file anyone can quietly edit.

Trust does not come from one party's word. It comes from independent signed statements that anyone can line up and compare: the maintainer says hash H; one or more rebuilders, each with their own key, say they reproduced H. A signature can't be forged without its key, and a record in Rekor can't be silently removed.

Why side-by-side, always. Attestations are published whether they match or not — not only on failure. The presence of a signed statement is verifiable; its absence is not. "No complaints" can be manufactured by deleting a file; "three signed confirmations" cannot be faked without three keys. Confidence rests on what is present and signed, never on silence.

06 · ACKNOWLEDGEMENTS

Standing on others' work

This mechanism is not original to Odyssey, and it shouldn't pretend to be. The approach is inspired by guix challenge from GNU Guix, and more broadly by the Reproducible Builds project (reproducible-builds.org), which established independent rebuild verification as a standard across distributions. Odyssey applies these ideas with its own tooling — xbps, cosign, Rekor — but the credit for the model belongs upstream.