Distributing software and data archives reliably means more than serving files from a fast CDN. Users and downstream systems need to verify that what they downloaded is exactly what you published — unmodified in transit, unmodified at rest on mirrors, and traceable to a specific build or release process.

Traditional approaches use detached PGP signatures or standalone hash files, but these have persistent usability problems: key management is complex, key distribution is fragile, and most users never actually verify signatures. Sigstore offers a modern alternative with keyless signing, transparency logs, and a verification model that can be automated without manual key management.

This guide covers how to integrate Sigstore signing into your release workflow for download archives, how the transparency log (Rekor) provides tamper evidence, and what the verification experience looks like for users.

Why Sigstore for archives

The PGP problem

PGP/GPG signing for downloads has been the standard for decades, but in practice:

  • Key management is hard: generating, storing, rotating, and revoking keys requires operational discipline most projects lack
  • Key distribution is fragile: users must find and trust the correct public key, often from the same server they're verifying against
  • Verification is rare: studies consistently show that very few users actually verify PGP signatures on downloads
  • Revocation is broken: PGP key revocation mechanisms are poorly supported and rarely checked

What Sigstore provides

Sigstore replaces long-lived key management with short-lived, identity-bound certificates:

  1. Keyless signing: the signer authenticates via OIDC (GitHub, Google, etc.), receives a short-lived signing certificate from Fulcio (Sigstore's CA), and signs the artifact
  2. Transparency log: the signature is recorded in Rekor, a public append-only transparency log. This creates a verifiable, timestamped record that the artifact was signed
  3. Verification without keys: verifiers check the signature against the Rekor log entry and the Fulcio CA root, without needing to manage or distribute public keys
  4. Automated verification: tools like cosign and sigstore-go can verify signatures programmatically in CI/CD pipelines and package managers

Signing workflow for download archives

Prerequisites

  • cosign CLI installed (part of the Sigstore project)
  • An OIDC identity (GitHub account, Google account, or other supported provider)
  • Your archive files ready for signing

Step 1: Sign the archive

# Keyless signing with OIDC identity
cosign sign-blob --output-signature archive-v2.4.1.tar.gz.sig \
  --output-certificate archive-v2.4.1.tar.gz.cert \
  archive-v2.4.1.tar.gz

This will:

  1. Open a browser for OIDC authentication
  2. Obtain a short-lived certificate from Fulcio
  3. Sign the archive with the ephemeral key
  4. Record the signature in Rekor
  5. Output the signature and certificate files

Step 2: Publish alongside the archive

Distribute three files:

  • archive-v2.4.1.tar.gz — the archive
  • archive-v2.4.1.tar.gz.sig — the Sigstore signature
  • archive-v2.4.1.tar.gz.cert — the signing certificate

Step 3: Verify (user-side)

cosign verify-blob --signature archive-v2.4.1.tar.gz.sig \
  --certificate archive-v2.4.1.tar.gz.cert \
  --certificate-identity [email protected] \
  --certificate-oidc-issuer https://accounts.google.com \
  archive-v2.4.1.tar.gz

The verifier checks:

  • The signature matches the file content
  • The certificate was issued by Fulcio during the signing window
  • The signature is recorded in Rekor
  • The identity and OIDC issuer match the expected signer

Transparency logs and tamper evidence

Rekor, the Sigstore transparency log, provides a critical property: if a signature exists, it must appear in the log. This means:

  • An attacker who modifies an archive cannot produce a valid signature without creating a Rekor entry (which would be publicly visible and auditable)
  • Historical signatures can be verified even after the short-lived certificate expires, because the Rekor timestamp proves the signature was created while the certificate was valid
  • Monitors can watch the Rekor log for unexpected signatures on your artifacts

Monitoring Rekor

Set up monitoring to detect unexpected signing activity:

# Search Rekor for entries related to your artifact
rekor-cli search --artifact archive-v2.4.1.tar.gz

# Search by signer identity
rekor-cli search --email [email protected]

If you see entries you didn't create, investigate immediately — someone may have signed a modified version of your archive.

CI/CD integration

For automated release pipelines, Sigstore supports workload identity (no interactive OIDC flow):

GitHub Actions

- uses: sigstore/cosign-installer@v3
- name: Sign release archive
  run: |
    cosign sign-blob --yes \
      --output-signature $-$.tar.gz.sig \
      --output-certificate $-$.tar.gz.cert \
      $-$.tar.gz
  env:
    COSIGN_EXPERIMENTAL: 1

GitHub Actions provides an OIDC token automatically, so the signing is fully non-interactive and the signer identity is tied to the GitHub repository and workflow.

Common mistakes

Not pinning the expected signer identity in verification. If you verify a signature without specifying --certificate-identity and --certificate-oidc-issuer, any valid Sigstore signature will pass. Always pin the expected identity.

Forgetting to publish the certificate file. Without the .cert file, offline verification is impossible. Users would have to query Rekor to reconstruct the certificate chain.

Signing without recording in Rekor. Cosign records to Rekor by default, but if you disable it (e.g., for air-gapped environments), you lose the transparency log benefits. Only disable Rekor logging if you have an alternative audit mechanism.

Not verifying your own signatures. After signing, always verify the archive yourself to confirm the signature, certificate, and Rekor entry are correct before publishing.

Mixing PGP and Sigstore without clear documentation. If you're transitioning from PGP to Sigstore, clearly document which verification method applies to which release. Don't leave users guessing.

When not to use Sigstore

  • Air-gapped environments where internet access for Fulcio/Rekor is not available — use traditional key-based signing instead
  • Environments that require long-lived keys for compliance reasons — Sigstore's keyless model may not satisfy specific regulatory requirements
  • Very small projects where the overhead of Sigstore tooling exceeds the security benefit — a simple SHA-256 checksum file may be sufficient

Related reading on wplus.net