Verify what you installed

This page lists what each urna release artifact can be checked against and the command that checks it. The coverage is not uniform: build provenance exists for the five binary archives only, and the npm package and the PyPI wheels have no provenance at all. The examples use v0.5.1.

A matching digest proves the bytes are the ones the release published. An attestation proves which repository and workflow produced them. Neither says anything about a .urna file you open later; that is what urna validate and the citation hashes are for.

What each artifact hasCopy Anchor Link

What each install channel checks on its own:

Check a digestCopy Anchor Link

Each archive and the payload have a <name>.sha256 file in sha256sum format (<hex> *<name>):

sha256sum -c urna-x86_64-unknown-linux-musl.tar.xz.sha256
sha256sum -c urna-embedder-payload.tar.gz.sha256

On macOS, use shasum -a 256 -c with the same file. sha256.sum covers the five archives and the npm package in one file:

sha256sum -c --ignore-missing sha256.sum

A digest fetched from the same server as the file catches a corrupted or truncated download. It does not catch a file replaced together with its digest; the attestations below do.

Check build provenance for an archiveCopy Anchor Link

The release workflow signs a SLSA provenance statement for each archive with GitHub's attestation service. It binds the archive's digest to the workflow run in hoffresearch/urna that built it. Verify with the GitHub CLI:

gh attestation verify urna-x86_64-unknown-linux-musl.tar.xz --repo hoffresearch/urna

The statement's subjects also include the archive's .sha256, its README.md and the urna binary inside it, so the same command accepts an extracted binary.

Check the payload, the SBOM and the other assetsCopy Anchor Link

Every asset of the release is a subject of GitHub's release attestation. Verify any of them against the tag:

gh release verify-asset v0.5.1 urna-embedder-payload.tar.gz --repo hoffresearch/urna
gh release verify-asset v0.5.1 urna.cdx.xml --repo hoffresearch/urna

This proves the file is the one attached to the v0.5.1 release. It says nothing about how the file was built.

GitHub marks the v0.5.0 and v0.5.1 releases as immutable, a setting that locks a published release's assets and tag.

Read the dependency list out of the binaryCopy Anchor Link

The binaries are built with cargo-auditable, which embeds the resolved dependency tree in a .dep-v0 section. cargo audit reads it back and checks it against the RustSec advisory database:

cargo audit bin ~/.local/bin/urna

The full dependency list is also in the SBOM, urna.cdx.xml.

Check the release tagCopy Anchor Link

Release tags are annotated and SSH-signed. The release workflow verifies the signature against .github/allowed_signers before anything builds. Check it yourself from a checkout:

git clone https://github.com/hoffresearch/urna && cd urna
git -c gpg.ssh.allowedSignersFile=.github/allowed_signers verify-tag v0.5.1

The pip wheel and the npm packageCopy Anchor Link

Neither has a provenance statement today. For the wheel, pip checks each file against the hash PyPI serves, and nothing ties the wheel to a workflow run. The npm wrapper downloads the release archive over HTTPS and checks no digest. When you need provenance, download the release archive yourself, verify it as above, and put the binary on PATH (see installation). You can also verify a binary installed by another channel against the attestation, since the provenance subjects include the binary.

To install on a machine with no network after verifying here, see air-gapped install.