Sigstore バンドル検証ツール

What a bundle is

Sigstore signs software without long-lived keys. A CI job or a developer proves who they are to an OpenID Connect provider, the Fulcio certificate authority issues a certificate valid for ten minutes that names that identity, the client signs with a throw-away key, and the signature is recorded in the Rekor transparency log. Everything a verifier needs to check that afterwards — offline — travels in a bundle, the .sigstore.json file defined by the protobuf-specs of the project: the signing certificate (or the hint of a managed key), one or more Rekor entries with their inclusion proofs, optional RFC 3161 time-stamps, and the content — either a signature over a file's digest (messageSignature, what cosign sign-blob produces) or a DSSE envelope around an in-toto attestation (what npm provenance and GitHub artifact attestations produce). Versions 0.1, 0.2 and 0.3 of the bundle format are all read, with the structural rules each version adds.

The order of verification

The verifier follows the Sigstore client specification, because the steps depend on one another:

1. When was it signed? A certificate that lived ten minutes is only meaningful together with a trusted time. Each Rekor entry with an integrated time carries a signed entry timestamp, the log's signature over the entry; RFC 3161 time-stamps are signed by a time-stamp authority. Only times whose signatures verify against the trusted root count. Rekor v2 logs no longer provide an integrated time, so their bundles need a time-stamp.
2. Was the certificate valid then? The Fulcio certificate must chain to a Fulcio CA of the trusted root that was valid at every verified time, carry the code-signing usage, and embed at least one SCT from a certificate-transparency log of the trusted root — proof that the certificate itself was published.
3. Is the entry really in the log? The inclusion proof is a Merkle audit path from the entry to a root hash, and that root hash must sit in a checkpoint signed by a log of the trusted root. The entry body — hashedrekord or DSSE in versions 0.0.1 and 0.0.2, or the older intoto 0.0.2 — must describe this signature, this digest and this certificate, not some other.
4. Does the signature cover your file? For a message signature, the digest of your file must equal the signed digest and the signature must verify over it. For a DSSE envelope, the signature covers the envelope's pre-authentication encoding, and your file must be one of the statement's subjects.
5. Is it the signer you expect? A valid Sigstore signature only proves that someone signed. The identity — the certificate's subject alternative name, such as a GitHub workflow URI — and its OIDC issuer must be the ones you expect. Leave them empty and the page warns, exactly where cosign stops with “--certificate-identity is required”.

Every failed step is listed with what was expected and what was found. The certificate's CI claims — repository, commit, ref, workflow, trigger, run — are shown as Fulcio recorded them.

The trusted root

The keys of Fulcio, Rekor, the CT logs and the time-stamp authorities come from trusted_root.json, which Sigstore distributes through TUF. The page carries a snapshot of the public-good root, byte for byte the TUF target, so nothing is fetched while a bundle is checked; the date of the snapshot is shown with each result. For a private Sigstore deployment or the staging instance, paste its own trusted_root.json. A bundle signed with a managed key (cosign sign-blob --key) has no certificate: paste the PEM public key instead.

A second, independent opinion

The verification on this page is our own code, run against the 70 cases of the official sigstore-conformance suite. If you want independent code to agree, press “Check with sigstore-js”: our server verifies the same bundle with sigstore-js, the reference implementation npm uses. The server receives the bundle, the file's digest and the identity you expect — never the file. Node's cryptography cannot verify a signature over a digest, so for a message signature that one step is checked with the same prehashed verification as this page; everything else is sigstore-js's own. An Ed25519 signature covers the file itself and cannot be checked from a digest; the server says so.

The examples are bundles of the conformance suite. For npm packages the npm provenance checker fetches the bundles from the registry and checks them against the package; the attestation inside a DSSE bundle is decoded in detail by the in-toto attestation viewer. How to sign releases this way, and how to verify them in CI, is explained in Signing releases with Sigstore; how it compares with GPG keys, in Sigstore vs GPG signing.