Signed Manifest or Checksum¶
Signed integrity record — instantiates Restricted-Issuance / Open-Verification Design
Publishes the expected content of a release or file set as a signed list of cryptographic hashes, so a verifier can catch a single swapped, corrupted, or injected file and refuse it.
A signed manifest or checksum binds not just who issued something but exactly what it should contain. The issuer computes a cryptographic hash of every file in a release, dataset, package, or bill of materials, writes those fingerprints into a manifest, and signs the manifest. A verifier then recomputes the hashes of what they actually received and compares them against the signed list — and any file that doesn't match is rejected. Its defining move is turning verification from "was this signed by the issuer?" into "is this the precise content the issuer published, byte for byte?" — closing exactly the gap a bare signature leaves open, where a validly-signed but wrong, swapped, or partial payload sails through unexamined.
Example¶
A Linux distribution ships its packages through hundreds of untrusted community mirrors. Alongside the packages it publishes a signed index — a manifest listing the SHA-256 hash of every package — signed with the distro's release key. When a user's package manager pulls an update from whatever mirror is nearest, it doesn't trust the mirror at all: it recomputes each downloaded file's hash and checks it against the signed manifest. A mirror that has quietly swapped in a backdoored package fails instantly — the tampered file's hash won't match the one the distro signed — and the install is refused before a single byte runs. The manifest lets the distro distribute through infrastructure it doesn't control, because the content certifies itself against a list only the distro could have signed.
How it works¶
- Enumerate expected content as hashes. The distinguishing payload is the inventory: a fingerprint of each file, so the signed unit describes a whole set's exact contents, not one opaque blob.
- Sign the manifest, not each file. One signature over the list of hashes covers everything it enumerates; tampering with any listed file breaks its hash and so breaks the manifest's promise.
- Verify by recompute-and-compare. The verifier hashes what arrived and diffs against the signed list — a check that needs only the files, the manifest, and the issuer's public key, so it works through any mirror or offline.
- Fail closed on any mismatch. The defined outcome for a hash that doesn't match is refuse — the payload is treated as corrupted or tampered, distinct from a manifest whose signature itself is bad.
Tuning parameters¶
- Hash strength and agility — which algorithm, and how readily a weakening one can be retired. A stronger hash resists collision attacks longer; the ability to migrate matters because a broken hash silently voids every manifest built on it.
- Coverage depth — files only, or files plus versions, dependencies, and provenance (an SBOM). Deeper coverage catches more substitution but grows what must be maintained and re-signed.
- Granularity — one hash for the whole artifact, per-file hashes, or a Merkle tree. Finer granularity enables partial and streaming verification at the cost of a larger manifest.
- Anti-rollback binding — whether a version or signed timestamp is bound in, so an attacker cannot replay an older, still-validly-signed manifest to force a downgrade.
When it helps, and when it misleads¶
Its strength is decoupling integrity from the delivery channel: a signed manifest lets content flow through mirrors, CDNs, and USB sticks nobody trusts, and still be verified — for both accidental corruption and deliberate substitution — at the far end, offline, by anyone. It closes the "signed but unexamined content" gap directly, because it forces a check of what was delivered against a signed inventory.
Its central failure mode is that a manifest proves the content matches what the issuer put in the manifest — not that the content is safe. If the issuer's build pipeline or source was compromised, the manifest faithfully certifies malicious files: every hash matches, every signature checks, and the result is a validly-signed backdoor. It is therefore easily misread as proof of safety rather than proof of unchanged-since-build. A broken hash function undermines it silently, and an unversioned manifest can be replayed to force a downgrade. The discipline is to pair the manifest with build provenance — attestations of how and from what the artifact was built, as formalized by frameworks like SLSA — so the signed content traces back to a trustworthy build, not merely to a consistent download.[n1]
How it implements the components¶
Signed Manifest or Checksum realizes the content-integrity side — the components that bind exact contents and define the mismatch outcome:
unforgeable_binding— the signature over the hash list binds the release's exact expected content to the issuer; altering any file breaks a hash and thus the binding, so the inventory cannot be forged without the signing key.verification_failure_state— it defines a precise verdict: any file whose recomputed hash differs from the signed manifest is refused as tampered or corrupted, distinct from a badly-signed manifest.
It consumes rather than provides the signing primitive and the public check itself (public_verification_rule, offline_verification_mode, issuer_verifier_boundary — that's Digital Signature); it does not guard the signing key's custody (protected_issuance_authority — Secure Hardware Issuer Module) or report a revoked key (revocation_and_freshness_channel — Certificate Revocation List or Status Endpoint).
Related¶
- Instantiates: Restricted-Issuance / Open-Verification Design — the signed inventory lets content be distributed by untrusted intermediaries yet verified by anyone against a list only the issuer could sign.
- Consumes: Digital Signature — the manifest is a signed artifact; the signature over the hash list is what makes the inventory trustworthy.
- Sibling mechanisms: Digital Signature · Secure Hardware Issuer Module · Public-Key Certificate · Certificate Revocation List or Status Endpoint · Issuer Key Ceremony · Notary or Official Stamp · QR Verification Code · Serial Number or Registry Lookup · Tamper-Evident Seal · Verifiable Credential
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Signed Manifest Or Checksum operates by preserves a signed inventory of expected file hashes as durable integrity and provenance evidence. That concrete deployed or enacted form is Record, Log & Register under the frozen taxonomy.
Nearest alternative: Representation, Specification & Plan — Although Representation, Specification & Plan can support this mechanism, the frozen evidence makes its operative form the act that preserves a signed inventory of expected file hashes as durable integrity and provenance evidence; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Security Studies & Intelligence Analysis
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: A signed list of expected cryptographic hashes is a software-distribution integrity control. NIST explicitly prescribes signatures and hashes for detecting altered packages; computing supplies hash and verification algorithms.
Related originating lineages:
- Computer Science & Software Engineering — Computer science and software-engineering practice supplies a parallel or contributing lineage for the mechanism's defining operation: publishes the expected content of a release or file set as a signed list of cryptographic hashes, so a verifier can catch a single swapped, corrupted, or injected file and refuse it.
- Engineering & Design — engineering_design contributes engineering design, reliability, and systems-safety practice to this mechanism's defining operation—Publishes the expected content of a release or file set as a signed list of cryptographic hashes, so a verifier can catch a single swapped, corrupted, or injected file and refuse it—without displacing the selected primary historical lineage.
- Library & Information Science — Manifest practice identifies the expected contents of an archival or released collection.
- Mathematics — Hash and signature primitives supply collision resistance and authenticity.
Review resolution: The blind reviewers disagree on primary lineage (computer_science versus security_intelligence). Authoritative or primary research supports security_intelligence as the best historical origin: A signed list of expected cryptographic hashes is a software-distribution integrity control. NIST explicitly prescribes signatures and hashes for detecting altered packages; computing supplies hash and verification algorithms. The cited NIST, Software Distribution Signatures and Hashes directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=cross_disciplinary_synthesis records lineage, while domain_reach=specialized records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
A signed manifest attests integrity and origin, never currency or safety. It will certify a release that is signed-but-vulnerable or signed-but-superseded exactly as faithfully as a good one, so it must be paired with anti-rollback/freshness to stop replay of an old manifest and with build provenance to earn the trust the signature only transports.
[n1] SLSA (Supply-chain Levels for Software Artifacts), an OpenSSF framework, defines graded requirements for build provenance — evidence of how an artifact was produced and from what source. It targets exactly the gap a signed manifest cannot close: content that is validly signed but built from a compromised pipeline. ↩