Block upgrades that change the signer identity - #6132
Open
samuv wants to merge 1 commit into
Open
Conversation
samuv
force-pushed
the
skills-sig/13-upgrade-guard
branch
from
July 29, 2026 08:01
591c621 to
f1a9a83
Compare
samuv
marked this pull request as ready for review
July 29, 2026 08:02
samuv
requested review from
ChrisJBurns,
JAORMX,
amirejaz,
aponcedeleonch,
jhrozek,
rdimitrov and
reyortiz3
as code owners
July 29, 2026 08:02
An upgrade re-resolves a mutable source, which is exactly when a compromised or transferred publisher would slip a differently-signed artifact into the pinned trust chain (RFC THV-0080). Upgrade planning now probes the candidate's signer identity — chain-of-trust verification only, no install — and blocks the upgrade with a dedicated signer-change-blocked status when it differs from the identity the lock file records, or when the candidate is unsigned. Blocked plans carry no pinned reference, exactly like ref changes: preview reports them, fail-on-changes counts them as changes, and a plain upgrade exits with the policy-rejection code pointing at --allow-signer-change. The explicit override verifies the candidate chain-of-trust-only and re-records the newly observed identity in the lock entry, so the change is deliberate and diff-visible rather than a silent rotation. Entries without recorded provenance are unaffected. Part of #5899. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
samuv
force-pushed
the
skills-sig/13-upgrade-guard
branch
from
July 29, 2026 08:09
f1a9a83 to
8cb954f
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## skills-sig/12-sync-reverify #6132 +/- ##
==============================================================
Coverage ? 72.47%
==============================================================
Files ? 740
Lines ? 76358
Branches ? 0
==============================================================
Hits ? 55344
Misses ? 17083
Partials ? 3931 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
4 tasks
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
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.
Note
Stack 2 of RFC THV-0080 (tracking issue #5899) — part of stack #6128: #6091 ← #6121 ← #6129 ← #6131 ← this.
Summary
An upgrade re-resolves a mutable source — exactly the moment a compromised or transferred publisher could slip a differently-signed artifact into the pinned trust chain. This PR closes that gap:
planUpgradeverifies the candidate artifact (chain-of-trust only, no install — preview stays install-free) and compares the observed identity against the recorded one. OCI candidates verify directly; git candidates are re-resolved at the pinned commit for their signature material.signer-change-blockedstatus: a differing identity — or an unsigned candidate against a signed entry — blocks the plan with no pinned reference, mirroringref-change-blockedexactly: preview reports it,--fail-on-changescounts it as a change (exit 2), and a plain upgrade exits with the policy-rejection code (exit 4) pointing at the escape hatch. The blocked outcome carriesnew_signer_identityso the user sees who signed the candidate.--allow-signer-change(CLI, client, API): the explicit override verifies the candidate chain-of-trust-only and re-records the new identity in the lock entry — a deliberate, diff-visible trust rotation rather than a silent one. This is also the recovery path the install-time signer-mismatch error now points at.Type of change
Test plan
task lint-fix, 0 issues)--allow-signer-changeupgrades and re-records the new identity; preview parity (same block reported, nothing installed or rewritten); exit-code matrix rows (policy rejection, preview-informational, fail-on-changes interaction).task docsregenerated (new flag + API field).Does this introduce a user-facing change?
Yes, behind the experimental gate:
thv skill upgraderefuses to move a skill to an artifact signed by a different identity (or unsigned) unless--allow-signer-changeis passed.Generated with Claude Code