Docs · Task 06 · Docs for 1.0.10

Verify what you downloaded

Every file on the release is signed. You can check that one came from our build pipeline without trusting us — the proof is in a public transparency log, not on a server we control.

Step 1

Get the file and its bundle

Each artifact ships beside a .sigstore.json of the same name. You need both. There are 94 files on the release — 47 payload files, each paired 1:1 with its own bundle.

gh release download v1.0.10 --repo uniQ-Ventures/armore-edge-public \
  --pattern 'armore-darwin-arm64' \
  --pattern 'armore-darwin-arm64.sigstore.json'

Or download both from the release page in a browser.

Step 2

Verify it

cosign verify-blob \
  --bundle armore-darwin-arm64.sigstore.json \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/uniQ-Ventures/' \
  armore-darwin-arm64

Verified OK

That checks three things at once: the bytes you hold match the digest that was signed, the signature was made by a certificate issued to a GitHub Actions workflow in our organisation, and the whole thing is recorded in a public log you can inspect independently.

The repo you download from is not the repo that signs. Releases are published from armore-edge-public, but they are signed by the release workflow in armore-edge-internal. The certificate says so:

# the identity on the signing certificate
https://github.com/uniQ-Ventures/armore-edge-internal/.github/workflows/release.yml@refs/heads/integration/v2.0

So if you tighten the identity above to armore-edge-public — the natural thing to do — verification fails with “none of the expected identities matched”, on a perfectly good file. That is a false alarm, not a compromised download. Pin to armore-edge-internal if you want a narrower check than the organisation-wide one above.

Step 3

Prove the check actually checks

“Verified OK” on its own proves nothing — a verifier that always passed would print it too. Change one byte and run it again:

cp armore-darwin-arm64 tampered
printf '\x00' >> tampered

cosign verify-blob --bundle armore-darwin-arm64.sigstore.json \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/uniQ-Ventures/' \
  tampered

Error: error verifying bundle: matching bundle to payload:
  bundle ="1d14d00d74648c6e95f4e14c30c0ced163f3cf99dc2023e7144023a2003bff4a"
  payload="177f4d1c832f4fdd49368b06b971d97da413d17943c00f7e845510e3af3a4a4a"

One appended byte, and it refuses. Now the pass in step 2 means something — and that is the same reasoning we would like you to apply to everything else we say.

Step 4

Two commands that will not work

Stated here so you do not spend time concluding something is broken.

`gh attestation verify` returns 404

gh attestation verify armore-darwin-arm64 --repo uniQ-Ventures/armore-edge-public

Error: HTTP 404: Not Found
  (…/attestations/sha256:1d14d00d…bff4a?predicate_type=https://slsa.dev/provenance/v1)

This is expected, and it is not a signal that the file is untrustworthy. That command looks for SLSA build provenance, which is a different artifact from a Sigstore bundle. We publish the bundle; we do not publish SLSA provenance. cosign verify-blob is the check for these files.

The top-level `sha512` in a manifest names a different file

In latest-mac.yml / latest.yml / latest-linux.yml, the sha512 at the top of the file is not the one for the artifact you downloaded. Match your own filename inside the files: list and use that entry’s hash.

Step 5

If you would rather not install cosign

Every installer’s SHA-512 is named in a signed manifest beside it, so you can compare bytes with tooling you already have:

BASE=https://github.com/uniQ-Ventures/armore-edge-public/releases/download/v1.0.10
curl -fLO "$BASE/latest-mac.yml"   # or latest.yml (Windows) / latest-linux.yml
openssl dgst -sha512 -binary <your-file> | openssl base64 -A; echo
grep -A2 <your-filename> latest-mac.yml

This is weaker than step 2 and worth knowing why: it proves the file matches a manifest you also downloaded from us. The cosign check proves the file matches a signature recorded in a public log we do not control. Use it if you cannot install cosign; prefer step 2 if you can.

Also on the release

22 bills of materials

CycloneDX SBOMs, one per component, each with its own Sigstore bundle. They list what is inside the thing you are about to install — you can read them before you run anything.

A Sigstore bundle is not an OS-trusted signature. It binds a digest to the repository, workflow and commit that produced it. It does not quiet SmartScreen on Windows and it is not what Gatekeeper checks on macOS — those are separate mechanisms, covered on install and first run.

Witnessed

These three were run, not asserted

✓

The command above returns Verified OK — and the two ways it can fail both fail. Run against the released binary on 15 October 2026.

1 · As documented, organisation-wide identity — Verified OK, exit 0.
2 · Identity tightened to armore-edge-public, the mistake this page warns about — fails, exit 1, and the certificate it reports is the one printed above, verbatim: …/armore-edge-internal/.github/workflows/release.yml@refs/heads/integration/v2.0. A perfectly good file, refused.
3 · One byte appended, Step 4's test — fails, exit 1, on a digest mismatch rather than a signature error. The bundle is bound to the bytes, so changing them breaks the binding before the signature is ever reached.