Skip to content

Seed-Artifact Signature Verification

A seed-verification check — instantiates Self-Hosted Bootstrap Construction

Checks the starting seed's cryptographic signature and hash against a trusted reference before any stage is built on top of it.

Seed-Artifact Signature Verification is the gate at the very bottom of the ladder. Before the seed compiler, image, or binary is used to build anything, its cryptographic signature and content hash are checked against a trusted reference — so the whole chain rests on a seed whose identity and integrity are proven, not assumed. Its defining move is anchoring trust at the seed with cryptographic attestation and refusing to admit anything that fails it, establishing the integrity boundary around the one artifact every descendant inherits from. It verifies that the seed's bits are the trusted bits; it does not vouch for the seed's behaviour (that a different mechanism handles), nor build a minimal seed, nor make later stages reproducible.

Example

A team bootstrapping a toolchain downloads the seed compiler binary that everything else will be built with. Before a single stage runs, they verify the binary's detached signature against the publisher's pinned public key, and compare its SHA-256 against a hash obtained through an independent channel — increasingly, an entry in a transparency log such as Sigstore's. If signature and hash both match the trusted reference, the seed is admitted and its attestation is recorded as the first link in the provenance chain. If either fails, the seed is rejected before it can contaminate one downstream stage. The check is cheap and absolute, and it sits exactly where a poisoned input would otherwise ride upward through every rung of the build.

How it works

The distinguishing steps are cryptographic and out-of-band: verify a signature over the artifact using a pinned or logged trust anchor, and independently compare the artifact's hash to a reference fetched through a separate channel so a single compromised source cannot forge both. A match admits the seed and writes the attestation into provenance; a mismatch rejects it outright. The strength of the whole check reduces to the strength of the reference channel — the key or hash you compare against.

Tuning parameters

  • Trust anchor — what trust is rooted in: a pinned public key, a CA, a transparency log, or several independent channels at once. More independent anchors are harder to spoof but harder to maintain.
  • Verification strictness — signature only, or signature plus hash plus transparency-log inclusion. Stricter raises assurance and operational cost together.
  • Key-distribution model — how the reference key or hash reaches you out of band. The entire check is only as strong as this channel.
  • Revocation and freshness — whether revoked keys and expected versions are checked, so a validly-signed but withdrawn or downgraded seed is still caught.

When it helps, and when it misleads

Its strength is a cheap, sharp gate that stops a tampered or misidentified seed from poisoning every descendant, and it anchors the provenance chain with the seed's attested identity. Its limit is precise and easy to over-trust: a valid signature proves the bits are the ones the signer released — not that the signer's own build was clean. A seed compiler subverted at its source and then honestly signed verifies perfectly. This is exactly the Reflections on Trusting Trust attack, which signatures cannot catch and which is why diverse double-compilation, not signatures alone, is the real defense against a malicious seed.[1] The misuse is treating a green signature as proof the seed is safe rather than proof it is authentic. The discipline is to pair signature verification (integrity) with an independent behavioural check for trust, and to protect the reference-key channel as carefully as the seed itself.

How it implements the components

  • seed_integrity_boundary — the signature-and-hash check is the enforced boundary keeping tampered or misidentified bits out of the seed slot.
  • trusted_minimal_seed — it is what converts a candidate seed into a trusted one the rest of the chain may build on.
  • bootstrap_provenance_chain — the recorded attestation becomes the first, anchoring link of the chain of custody.

It does not build or supply a minimal bootable seed (alternate_seed_path — Minimal Rescue-Image Bootstrap), does not detect a behaviourally subverted but validly-signed seed (independent_stage_verification_path — Diverse Double-Compilation Check), and does not make downstream builds deterministic (post_bootstrap_reproduction_test — Reproducible Bootstrap Build).

Notes

Signature verification protects the seed slot but relocates the root of trust one level down — to the reference key or hash channel. That is a real improvement (a public key is far smaller and more stable than a compiler, and easier to audit and pin) but not a dissolution of the problem: the channel that delivers the reference is now the thing that must be trusted, and it deserves the same scrutiny as the seed.

References

[1] Ken Thompson's Reflections on Trusting Trust (1984) showed a compiler can be modified to insert a backdoor and to re-insert that modification whenever it compiles itself — invisible in all source. A valid signature over such a compiler verifies faithfully, which is why signatures establish integrity but not trust; diverse double-compilation is the standard countermeasure. ↩