Verify your build — QERYX Docs

Read the release manifest

Every release is described by one signed document: the hash of every artifact on every channel, the source commit it was built from, and its anchor in the transparency log. The manifest is signed with ML-DSA-87 under FIPS 204 §5.2 framing — 0x00 || len(ctx) || ctx || M, ctx QERYX-RELEASE-MANIFEST-v1.

qeryx-release-1.0.0.json — shape

{
  "schema": "QERYX-RELEASE-MANIFEST-v1",
  "release_tag": "v1.0.0",
  "repo_head": "<git sha1>",
  "artifacts": [
    {
      "platform": "android",
      "channel": "direct",
      "filename": "qeryx-1.0.0.apk",
      "sha256": "<hex>",
      "sha384": "<hex>"
    }
    // …one entry per platform × channel
  ],
  "build_attestation_sha256": "<hex>",
  "sbom_sha384": "<hex>",
  "kts_anchor": { "seq": 0, "root_hash": "<base64>" }
}

The per-channel hash law

Every distribution channel of the same release carries the same bytes: the manifest's Android entries must share one SHA-256, and the iOS entries share one. On iOS, platform notarization re-signs the bundle, so the manifest publishes both the pre-signing and post-signing hashes — you verify against what actually arrives on the device.

Run the three checks

Three commands: verify the signature, hash your artifact, confirm the log covers the release. If all three pass, the binary you hold is the binary the manifest describes.

the verification path

# 1 — verify the manifest signature (ML-DSA-87)
qeryx-attest verify \
  --public release-signing.pub \
  --input qeryx-release-1.0.0.json \
  --signature qeryx-release-1.0.0.json.sig

# 2 — hash your downloaded artifact, compare to artifacts[]
shasum -a 256 qeryx-1.0.0.apk

# 3 — confirm the transparency log covers the release
curl https://api.qeryx.com/api/v1/kts/proof/by-uuid/<release-uuid>

Why the third check matters

The release leaf is anchored in KTS, the same append-only log that holds identity keys: a 2-of-3 multi-witness quorum (verify-only today — operator equivocation is detected, not prevented) plus three external Ed25519 auditor slots that ship dormant, holding placeholder keys until auditors are onboarded; registry expansion is release-gated by design. A release published to you but hidden from the log is a release the checks refuse.

Witness the build

A single build machine signing releases is a single machine to compromise. Q-Build-Attest routes every release through a witness quorum instead: each witness pulls the same commit, rebuilds inside the pinned container, hashes the trees byte for byte, and refuses to contribute a signature share if its bytes diverge.

What the attestation carries

Per-witness ML-DSA-87 signatures over the canonical attestation bytes (ctx QERYX-Q-BUILD-ATTEST-v1) plus a threshold aggregate that verifies under one group key no single witness controls. Attestations expire after 90 days, and a persisted sequence floor refuses rollback to an older, still-valid build.

Know where this stands today

UPDATE CHAIN — STATED EXACTLY

Build-attestation manifest published (ML-DSA-87, ctx QERYX-attest-v1); update-authenticity trust-root registry not yet claimed.

The signing helper and the witness protocol live in crypto-core today. Public manifest URLs appear on this page when the public release channel serves them — a link ships when its artifact does, and not before.

05The verifier questions — asked before the manifest is trusted

Interrogate the manifest.

Why can't iOS builds be fully reproducible?

Platform notarization rewrites the code-signature load command and re-stamps the bundle, so a third party cannot rebuild to the exact distributed bytes. We compensate by publishing both pre- and post-signing hashes and using one notarized artifact across every channel — the gap is named, not papered over.

What stops a malicious update signed with a stolen key?

The witness quorum: one stolen key yields one signature share, and the honest witnesses cannot reproduce malicious bytes, so the threshold signature never assembles. The remaining honest gap is the trust-root registry for update authenticity — not yet claimed, per the status above.

Can I verify without any QERYX tooling?

Steps two and three, yes — any SHA-256 tool and any HTTPS client. Step one needs an ML-DSA-87 verifier; qeryx-attest is the reference implementation, and the manifest format is documented so an independent one can be written against FIPS 204 alone.

Next: the source, the licenses, the review path