Summary
The .sigstore.json attestation bundles attached to releases (e.g. v1.15.0, artifact sfw-linux-x86_64) cannot be successfully verified using either the GitHub CLI (gh attestation verify) or the reference sigstore-python client, due to two separate issues. This makes it effectively impossible for an end user to verify the authenticity of downloaded binaries using standard tooling, which somewhat defeats the purpose of shipping attestations at all.
Environment
gh version: 2.49.0+ (attestation verify supported)sigstore-python version: 4.5.0- Artifact:
sfw-linux-x86_64 from SocketDev/firewall-release v1.15.0
- Attestation bundle:
SocketDev-firewall-release-attestation-37390311.sigstore.json
Issue 1 — gh attestation verify cannot construct a matching policy
The attestation's signing certificate has a Subject Alternative Name of https://dotcom.releases.github.com — this indicates it was signed via GitHub's internal release-signing infrastructure rather than a standard GitHub Actions OIDC workflow identity (which would look like https://github.com/OWNER/REPO/.github/workflows/...).
gh attestation verify requires --owner or --repo to construct its verification policy.
There does not appear to be a gh attestation verify flag that allows specifying a custom --cert-identity independent of --owner/--repo — attempting to omit both returns:
This effectively makes gh attestation verify unusable for this bundle, regardless of how the identity flags are constructed.
Issue 2 — Bundle omits tlogEntries, which sigstore-python requires despite the spec not mandating it
The bundle contains only an RFC3161 timestamp (rfc3161Timestamps) and no Rekor transparency log entry (tlogEntries). Per the Sigstore bundle spec, transparency log entries are not required — RFC3161 timestamp-only bundles are valid.
However, sigstore-python 4.5.0 fails to parse the bundle at all:
```
sigstore.models.InvalidBundle: failed to load bundle: 1 validation error for Bundle
verificationMaterial.tlogEntries
Field required [type=missing, input_value={'timestampVerificationDa...AllbdnorYRTm9mxkZaQ=='}}, input_type=dict]
```
This appears to be a sigstore-python bug/limitation — the Pydantic model marks tlogEntries as a required field even though the spec treats it as optional when RFC3161 timestamps are present.
Impact
As it stands, there is no supported, documented way for a user to verify these release attestations using standard Sigstore tooling. Given that the entire point of shipping attestations is to let users establish trust in the binary they're running, this is a meaningful gap — especially notable for a security-focused product.
Happy to provide the full bundle JSON or additional logs if useful.
Summary
The
.sigstore.jsonattestation bundles attached to releases (e.g.v1.15.0, artifactsfw-linux-x86_64) cannot be successfully verified using either the GitHub CLI (gh attestation verify) or the referencesigstore-pythonclient, due to two separate issues. This makes it effectively impossible for an end user to verify the authenticity of downloaded binaries using standard tooling, which somewhat defeats the purpose of shipping attestations at all.Environment
ghversion: 2.49.0+ (attestation verify supported)sigstore-pythonversion: 4.5.0sfw-linux-x86_64fromSocketDev/firewall-releasev1.15.0SocketDev-firewall-release-attestation-37390311.sigstore.jsonIssue 1 —
gh attestation verifycannot construct a matching policyThe attestation's signing certificate has a Subject Alternative Name of
https://dotcom.releases.github.com— this indicates it was signed via GitHub's internal release-signing infrastructure rather than a standard GitHub Actions OIDC workflow identity (which would look likehttps://github.com/OWNER/REPO/.github/workflows/...).gh attestation verifyrequires--owneror--repoto construct its verification policy.There does not appear to be a
gh attestation verifyflag that allows specifying a custom--cert-identityindependent of--owner/--repo— attempting to omit both returns:This effectively makes
gh attestation verifyunusable for this bundle, regardless of how the identity flags are constructed.Issue 2 — Bundle omits
tlogEntries, whichsigstore-pythonrequires despite the spec not mandating itThe bundle contains only an RFC3161 timestamp (
rfc3161Timestamps) and no Rekor transparency log entry (tlogEntries). Per the Sigstore bundle spec, transparency log entries are not required — RFC3161 timestamp-only bundles are valid.However,
sigstore-python4.5.0 fails to parse the bundle at all:```
sigstore.models.InvalidBundle: failed to load bundle: 1 validation error for Bundle
verificationMaterial.tlogEntries
Field required [type=missing, input_value={'timestampVerificationDa...AllbdnorYRTm9mxkZaQ=='}}, input_type=dict]
```
This appears to be a
sigstore-pythonbug/limitation — the Pydantic model markstlogEntriesas a required field even though the spec treats it as optional when RFC3161 timestamps are present.Impact
As it stands, there is no supported, documented way for a user to verify these release attestations using standard Sigstore tooling. Given that the entire point of shipping attestations is to let users establish trust in the binary they're running, this is a meaningful gap — especially notable for a security-focused product.
Happy to provide the full bundle JSON or additional logs if useful.