ATLAS/TRUST MODEL/CRYPTOGRAPHIC SIGNING SHEET T / 02

How we sign releases to prevent counterfeits.

Every blueprint release carries three layers of cryptographic proof: a content fingerprint, a registry signature, and a publisher attestation. This page opens the hood on each layer — what it proves, what it doesn't, and how to verify it yourself.

◇ 04 · TAMPER EVIDENCE

Every release is content-addressed — like a wax seal on a letter.

When a steward publishes a release, the registry computes a SHA-256 hash of the exact tarball bytes and stores it in the package index. When arc install runs, it downloads the tarball, recomputes the hash locally, and compares. If a single byte differs — whether from CDN corruption, a man-in-the-middle, or a compromised mirror — the hashes won't match and arc refuses to install.

A content fingerprint is tamper evidence, not a safety attestation. It tells you nothing moved behind the steward's back — not that the code is correct. Trust still comes from identity and sponsorship; the seal is the receipt that guarantees you got the bytes that were reviewed.

VERIFICATION FLOW
STEWARD publisher REGISTRY metafactory index ARC CLI installer publish @scope/blueprint v1.2.0 compute SHA-256 of tarball store hash in package index sha256: a4f8c1d2e5... stored alongside version in the signed index arc install @scope/blueprint index entry + SHA-256 hash download tarball bytes compute SHA-256 locally compare: local = index? MATCH → install proceeds ✓ MISMATCH → reject + alert ✗
TAP TO EXPAND ↗
DEFENDS AGAINST
  • CDN tampering — a compromised edge node serving altered bytes
  • Bit-rot — storage corruption that silently alters the tarball
  • Supply-chain injection — an attacker who replaces the artifact after publish
◇ 05 · REGISTRY SIGNATURE

The fingerprint list is signed — like a letterhead on the envelope.

Tamper evidence (◇ 04) tells you the bytes didn't change. But if an attacker controls the index itself, they can substitute their own hash for a compromised tarball — and your hash check would pass against their hash. The registry signature closes that gap.

metafactory signs the entire package index with an Ed25519 key. The corresponding public key is compiled into the arc binary at build time — it can't be swapped at runtime. When arc fetches the index, it verifies the signature before trusting any hash in the list. A compromised mirror or man-in-the-middle can serve you a stale index, but they can't forge a valid signature.

Key rotation is versioned: when the signing key changes, arc releases carry the new public key and recognise both during a transition window. The old key is retired, not just supplemented — there is always exactly one active signing key.

VERIFICATION FLOW
REGISTRY Ed25519 private key SIGNED INDEX package hash list ARC CLI embedded public key maintain index of all hashes sign index with Ed25519 key signature appended to index private key: held by registry never leaves the server rotatable with version bump fetch signed index index + Ed25519 signature verify signature with public key public key is compiled into the arc binary at build time — cannot be swapped at runtime signature valid → trust hash list proceed to tamper evidence check
TAP TO EXPAND ↗
DEFENDS AGAINST
  • Man-in-the-middle — an attacker between you and the registry altering the index
  • Compromised mirror — a CDN or cache serving a forged index with substituted hashes
  • Index poisoning — injecting a rogue entry into the hash list to redirect installs
◇ 06 · PUBLISHER PROVENANCE

Proof of who built it — independent of us.

Registry signatures (◇ 05) prove that metafactory vouched for a release. But what if metafactory's signing key were compromised? Publisher provenance adds a second, independent opinion that doesn't trust us at all.

When a steward publishes from CI, Sigstore issues a short-lived signing certificate tied to their OIDC identity (their verified CI environment). The steward signs an attestation with this certificate, and the attestation is recorded in Rekor, a public, append-only transparency log. The entry cannot be modified or deleted — it's a permanent, third-party receipt that a specific identity produced a specific artifact at a specific time.

When arc install runs, it fetches the attestation from the transparency log, verifies the certificate chain back to the Sigstore root, and confirms the inclusion proof. The result: you know who built the artifact, verified by infrastructure that metafactory does not control.

VERIFICATION FLOW
PUBLISHER CI build environment FULCIO Sigstore CA REKOR transparency log ARC CLI verifier build release artifact OIDC token (CI identity) short-lived signing certificate sign attestation with cert record signed attestation append to immutable log Rekor log is append-only — entries cannot be modified or deleted after recording fetch attestation attestation + inclusion proof verify certificate chain verify Rekor inclusion proof confirm: who built this? Identity confirmed ✓ Independent of registry trust
TAP TO EXPAND ↗
DEFENDS AGAINST
  • Compromised registry key — even if our Ed25519 key leaks, the Sigstore attestation still holds
  • Insider threat — a rogue registry operator can't forge a publisher's identity
  • Retroactive tampering — the transparency log is append-only; history can't be rewritten
THREAT MODEL MATRIX

Which layers defend against which attacks.

ATTACK SCENARIO TAMPER EVIDENCE (SHA-256) REGISTRY SIGNATURE (ED25519) PUBLISHER PROVENANCE (SIGSTORE)
CDN serves altered tarball
Man-in-the-middle alters index
Compromised mirror / cache
Registry signing key leaked
Rogue registry operator
Publisher account takeover
Bit-rot / storage corruption
Retroactive history rewrite
DESIGN PRINCIPLE

No single layer is sufficient. SHA-256 stops tampering but trusts the index. Ed25519 secures the index but trusts the registry operator. Sigstore removes even that dependency — the transparency log is a third party that neither the publisher nor the registry controls. The three layers compose into defense in depth: each one assumes the layer below it might fail.

← Back to Trust Model
ESC