Integrity Checksum or Signature¶

Artifact — instantiates Open Reuse Publication Infrastructure

A checksum or cryptographic signature published beside an artifact so any stranger can verify the bytes they fetched are unmodified and from the claimed author before reusing them.

Open publication invites copies — mirrors, caches, forks, re-hosts — and every copy is a chance for corruption or tampering to slip in. Integrity Checksum or Signature is the verification layer that lets a consumer confirm, on their own machine, that the artifact they hold is exactly the artifact the author published. A checksum (a hash such as SHA-256) detects any change to the bytes; a cryptographic signature goes further and binds those bytes to an author's identity, so the consumer can also confirm who stands behind them. Its defining move is to shift trust from the channel to the content: it no longer matters whether you fetched the file from the origin, a mirror, or a stranger's cache — if the signature verifies against the author's key, the bytes are authentic. Where the manifest declares provenance, this proves it.

Example¶

A widely used open-source command-line tool is mirrored on dozens of sites worldwide. With each release the maintainers publish a SHA256SUMS file and a detached GPG signature over it (real anchors: SHA-256 hashing, PGP/GPG signatures, and increasingly Sigstore/cosign for keyless signing). A developer in a region that only reaches the project through a third-party mirror downloads the tarball, fetches the maintainer's public key from an independent keyserver, and runs the verify command. The hash matches and the signature checks out, so they proceed — but had the mirror injected a modified binary, the signature would have failed and the tampering would have been caught before the code ran. The same signature is what lets the project encourage mirroring in the first place: a mirror can serve the bits, but it cannot forge the author's signature over them.

How it works¶

The mechanism rests on two moves. Content-addressing: hashing the artifact produces a fixed fingerprint, and any change — one flipped bit — yields a different fingerprint, so corruption and substitution are detectable by recomputing and comparing. Identity binding: a signature uses the author's private key so that only the holder of that key could have produced it, and anyone with the public key can verify it. Crucially, verification is done by the consumer, offline, against a trust root they obtain independently (a published key, a packaged root certificate, an append-only transparency log). That independence is the whole point — it is what makes an untrusted mirror safe to use.

Tuning parameters¶

Checksum vs. signature — a bare hash detects accidental corruption but not a substitution by an attacker who also rewrites the published hash; a signature binds to an identity and resists that. The stronger guarantee costs key management.
Trust-root distribution — how consumers obtain the authentic public key — keyservers, trust-on-first-use, a transparency log, or a key shipped in the OS. This is the soft link: a signature is only as trustworthy as the key's authenticity.
Signing granularity — per-file, per-release, or per-commit. Finer signing localizes exactly what was tampered with, at more overhead.
Transparency logging — whether signatures are recorded in a public append-only log, so a forged or backdated signature is detectable after the fact.
Algorithm and rotation policy — hash/signature strength and how often keys are rotated or revoked.

When it helps, and when it misleads¶

Its strength is singular: it is the only mechanism here that makes untrusted copies safe, which is what lets an artifact be mirrored, cached, and forked freely without turning every re-host into a supply-chain risk.

Its failure modes cluster around two confusions. First, key management is the underbelly — a stolen signing key, or a consumer who accepts a key on first use and never checks it, defeats the whole scheme; the cryptography is rarely the weak point, the key handling is. Second, and more insidious, a valid signature proves authenticity, not virtue: a signed artifact can still be buggy, malicious, or unfit — "signed" means "genuinely from this author," never "safe" or "endorsed." The classic misuse is treating a green checkmark as a trust decision. The discipline that keeps it honest is to verify the trust root out-of-band, rotate and revoke keys deliberately, and never let "signed" stand in for "reviewed" — which is why reproducible builds matter, since they let a third party rebuild the source and confirm the signed bytes actually correspond to it.^[1]

How it implements the components¶

Integrity Checksum or Signature fills the authenticity-and-replication side of the archetype — the verification components, not the ones that describe or announce the artifact:

provenance_and_authorship_record — the signature is the verifiable proof of origin and authorship; it answers the "how do I confirm this is genuine?" clause of provenance with cryptography rather than narrative.
mirror_and_replication_policy — checksums and signatures are precisely what let copies be mirrored and replicated freely and still trusted; a safe replication policy hangs on "any copy that matches the published hash and signature is good."

It verifies but does not describe: it does not enumerate identity, version, and dependencies (that record is the Machine-Readable Manifest), mint the identifier, or host the artifact (Public Artifact Registry). It confirms authenticity, not safety or quality — no release-gate review is implied.

Instantiates: Open Reuse Publication Infrastructure — supplies the trust anchor that makes open, mirrored distribution safe to reuse.
Consumes: Machine-Readable Manifest — the signature is typically computed over the manifest and the payload it references, sealing the declared checksums.
Sibling mechanisms: Machine-Readable Manifest · Persistent Identifier Minting · Public Artifact Registry · Package Manager Distribution · Open License Declaration · Schema or API Specification Publication · Semantic Versioning or Release Scheme · Changelog and Release Notes · Deprecation Notice Feed · Example Corpus or Test Fixture · Reference Implementation Repository · Metadata Harvesting Endpoint · Community Contribution Guidelines

Notes¶

Keep integrity separate from trust. This mechanism answers "are these the author's exact bytes?" — not "is the artifact good, safe, or fit for my use?" Those questions belong to review, testing, and any safety/privacy release gate. Conflating a valid signature with an endorsement is the single most common way it misleads.

References¶

[1] A reproducible build is one where compiling the same source always yields byte-identical output, so an independent party can rebuild an artifact and confirm the signed binary matches the source. It is the corrective that turns a signature from "this author signed something" into "this author signed this verifiable thing." ↩