Reproducibility

A shared-cache binding requires Vega's own independent rebuild from source, not a single party's word.

Input-addressed store paths are global: the openssl path is the same hash for everyone, and Nix trusts a cache's signature to mean "this is the legitimate output of that derivation". So signing a path into the shared cache is the security-critical decision.

Two tiers

What gates a shared signature

• A github-hosted build claim: an OIDC-proven CI build attests the output. This is the claim Vega reproduces; an owner-controlled push is not a shared-tier claim.
• Independent Vega reproduction: the Vega reproducer rebuilds the same source and reproduces the exact output before the master key signs. This is the gate; distinct-owner agreement is shown as community corroboration but does not sign.
• A settling window, so a burst of attestations cannot promote before reproduction can act.
• Download demand (optional, off by default): a deployment may also withhold the global signature until an output has real fetch demand. This is a cost and attack-surface control, not a trust input, and a demand-lookup failure withholds rather than forces a signature.

The Vega reproducer

The independent rebuild is performed by vega-reproducer, an open builder Vega operates. It rebuilds the agreed derivation from source, and the NAR hash it produces (computed by nix, not asserted by any attester) is what the master key signs. Because the reproducer is public, you can audit exactly how Vega arrives at a shared signature rather than take it on faith.

Sybil resistance

• A single repository's attestation never carries the globally trusted key.
• The Sybil bar is Vega's own independent rebuild: a swarm of fresh accounts cannot make Vega's reproducer produce different bytes, so identities alone never buy a signature.

When a build diverges

If independent builds of the same derivation produce different outputs, the build is non-reproducible. Vega marks the output diverged, shows it on the status page, and never signs it into the shared tier. Divergence is a signal, not a failure: it means the source is not yet bit-for-bit reproducible.

The status page reports the verdict (diverged) and which builders disagree. It does not yet show a byte-level diff of the two outputs: that comparison (with diffoscope) runs in the reproduction worker, not at the edge. The causes are a small, well-understood set from reproducible-builds.org, each with a standard fix:

• Embedded timestamps (build date baked into the output): set SOURCE_DATE_EPOCH.
• Build paths leaking into the result (a /build/... or /tmp/... prefix): use -ffile-prefix-map / BUILD_PATH_PREFIX_MAP; for Go, build with -trimpath.
• Locale and collation changing sort order: build under LC_ALL=C.
• Archive metadata and file ordering (tar/zip mtimes, owners, directory order): normalize with a sorted, fixed-mtime archive (e.g. tar --sort=name --mtime=@$SOURCE_DATE_EPOCH --owner=0 --group=0).
• Randomness (seeds, UUIDs, temporary names embedded in the output): pin or remove the nondeterministic source.

After applying a fix, push again from CI; once Vega reproduces the new output, the divergence clears.

Revocation

A signed shared binding is removable, and every revocation is recorded in the transparency log alongside the promotion it undoes:

• A trusted Vega reproduction that diverges from an already-signed binding auto-revokes it. An untrusted community builder cannot: only a Vega-operated reproducer can retract.
• A Vega operator can force-revoke a binding for a takedown (restricted to configured admin logins).

The public, signed revocation list is at /api/revocations, which a Vega-aware client can consult; a revoked path is removed from the shared cache and cannot be silently re-promoted.

A shared binding therefore asserts that the output was independently rebuilt and agreed on, and that the record is auditable; it is not a claim that the source itself is benign.