Thank you for providing feedback! So I’ve been digging in to the distro use-case more to find a better solution that:
- Can verify Sigstore bundles for files
- Allows for offline verification with minimal manual “online” setup (analog to fetching and storing PGP keys for later verification use). Verification might happen at multiple stages, both for building the package in centralized build infrastructure or when a user is building a package locally from source.
- Revocation checks and updates to the root of trust can be done periodically online. Root of trust may be distributed via its own package which is updated periodically.
- Doesn’t require build toolchain (sigstore-go) or a runtime/many dependencies (sigstore-python)
If there are other qualities that are needed for distros, please let me know. I am spending time to engage with Sigstore folks to make sure your use-cases are covered and they get encoded in the PEP and documentation for posterity.
If those all look good, it seems that Cosign (another Sigstore CLI tool) builds and ships binaries for easy installation and also supports offline verification as long as the trust roots are downloaded.
# Download Cosign
wget https://github.com/sigstore/cosign/releases/download/v2.4.1/cosign-linux-amd64
# For offline verification, also need the Root of Trust.
# Can be grabbed from GitHub:
# https://github.com/sigstore/root-signing/blob/main/targets/trusted_root.json
wget https://raw.githubusercontent.com/sigstore/root-signing/refs/heads/main/targets/trusted_root.json
# Download CPython artifacts
wget https://www.python.org/ftp/python/3.13.0/Python-3.13.0.tgz
wget https://www.python.org/ftp/python/3.13.0/Python-3.13.0.tgz.sigstore
./cosign-linux-amd64 verify-blob \
--new-bundle-format \
--certificate-oidc-issuer 'https://accounts.google.com' \
--certificate-identity 'thomas@python.org' \
--bundle ./Python-3.13.0.tgz.sigstore \
# --offline and --trust-root optional for offline verification
--offline \
--trusted-root ./trusted_root.json \
./Python-3.13.0.tgz
This matches more closely to (3), let me know if this fits well for you. Also cc-ing @mgorny @stefanor and @thesamesam @hroncok for opinions on this.