Pin the sigstore action so release signing cannot break on an upstream resolve — Closes #230 - #231
Merged
Merged
Conversation
A commit-SHA pin fixes the action's revision, not the dependency closure that revision installs. At the pinned revision the action resolves its Python environment from a requirements file constraining only sigstore ~= 3.0 and requests ~= 2.28, without hashes, so the transitive closure is recomputed against the package index on every invocation. Pinning more strictly does not narrow it, because the unconstrained resolution is a property of the pinned code rather than of the reference that selects it. securesystemslib 1.5.0 declares its cryptography 48 requirement through an extra that the tuf to sigstore chain does not select, so the resolver admits that release alongside an earlier cryptography. Signature verification degrades without raising, and the TUF trust root verifies against 0 of 3 keys. The failure is confined to the signing step and precedes any artifact read, so the surrounding jobs complete: distributions build, the GitHub release is created, and the PyPI upload succeeds. A release reaches both channels carrying no sigstore bundles, and no job reports a failure. Revision v3.5.0 installs from a requirements file pinning 31 distributions by exact version under sha256 hashes, among them sigstore 4.5.0, cryptography 49.0.0, securesystemslib 1.4.0 and tuf 7.0.0. The closure is fixed at the revision rather than at the index, so no subsequent upload can perturb it. The interface is unchanged. v3.5.0 declares a strict superset of v3.0.0's inputs and removes none, and the single input this action passes is identical.
conradbzura
force-pushed
the
230-pin-sigstore-action
branch
from
September 2, 2026 15:46
6fce7a1 to
1a574ae
Compare
conradbzura
marked this pull request as ready for review
September 2, 2026 15:50
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Bump the signing action from revision v3.0.0 to v3.5.0 so the release pipeline resolves its signing environment once, at the pinned revision, rather than against the package index on every run.
A commit-SHA reference fixes the action's revision, not the dependency closure that revision installs. The existing pin is well formed — a 40-character SHA with a version comment, matching every other action reference in this repository — and it leaves the closure unconstrained, because at that revision the action installs from a requirements file carrying only
sigstore ~= 3.0andrequests ~= 2.28without hashes. Pinning more strictly does not narrow it: the unconstrained resolution is a property of the pinned code rather than of the reference that selects it.The exposure is live.
securesystemslib1.5.0 declares itscryptography >= 48requirement through an extra that thetuf→sigstorechain does not select, so the resolver admits that release alongside an earliercryptography, signature verification degrades without raising, and the TUF trust root verifies against 0 of 3 keys. The failure is confined to the signing step and precedes any artifact read, so the surrounding jobs complete and a release reaches both channels carrying no.sigstorebundles. Tracked upstream as sigstore/sigstore-python#1887.No published release is affected retroactively. v0.5, cut 2026-07-15, predates the break and carries both bundles. The next cut is what this protects.
Closes #230
Proposed changes
Fix the closure at the action revision
Change the single
uses:reference in.github/actions/publish-github-release/action.yamlto790bc6befb9d733738f18d8f895854b453640ec9, the tag object for v3.5.0.v3.5.0 differs in construction rather than in version alone. It installs from
requirements/main.txt, which pins 31 distributions by exact version under sha256 hashes, among themsigstore==4.5.0,cryptography==49.0.0,securesystemslib==1.4.0andtuf==7.0.0. The closure is fixed at the revision, so no subsequent upload to the index can perturb it.The interface is unchanged. v3.5.0 declares a strict superset of v3.0.0's inputs, adding
rekor-versionand removing none, and the single input this action passes is identical. The changelog records no breaking entries across the range.Verification
The YAML parses to four steps with the signing step resolving and its single input intact, the new SHA matches the v3.5.0 tag object, and
sigstore/gh-action-sigstore-pythonappears exactly once across.github/with the prior SHA absent from the tree. End-to-end confirmation requires a release run, which is the argument for landing this before the next cut rather than during it.