Re-verify stored signatures offline during sync - #6131
Open
samuv wants to merge 1 commit into
Open
Conversation
samuv
requested review from
ChrisJBurns,
JAORMX,
amirejaz,
aponcedeleonch,
jhrozek,
rdimitrov and
reyortiz3
as code owners
July 29, 2026 07:01
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## skills-sig/11-install-verify #6131 +/- ##
===============================================================
Coverage ? 72.49%
===============================================================
Files ? 740
Lines ? 76317
Branches ? 0
===============================================================
Hits ? 55327
Misses ? 17064
Partials ? 3926 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
samuv
force-pushed
the
skills-sig/12-sync-reverify
branch
from
July 29, 2026 07:48
3350f67 to
b5b92a8
Compare
11 tasks
Sync now re-verifies each managed entry's stored Sigstore bundle against the identity recorded in the lock file — entirely offline, via the embedded trust root — before an entry can count as current (RFC THV-0080). A failed re-verification is drift: check mode reports it (the CI gate covers signatures like it covers content drift), and apply mode reinstalls from the pinned reference, where install-time verification enforces the locked identity and heals the stored state. An OCI entry recording a signer identity without a stored bundle fails closed; git entries store no bundle by design — their signatures are re-verified when content is re-resolved. Adoption back-fills provenance from the stored bundle when one exists; otherwise adopting is the same trust decision as an unsigned install and now requires the explicit --allow-unsigned exception (new flag on sync, threaded through the API), recorded as unsigned in the entry. Part of #5899. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
samuv
force-pushed
the
skills-sig/12-sync-reverify
branch
from
July 29, 2026 08:09
b5b92a8 to
3a2f05e
Compare
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) — stacked on #6129 (install-time verification). Stack: #6091 ← #6121 ← #6129 ← this.
Summary
thv skill syncnow closes the verification loop the install PR opened: the trust state recorded at install time is re-checked on every sync, without network access.AlreadyCurrent. A failed re-verification is treated as drift:sync --checkreports it (exit 2 — the CI gate covers signatures exactly like content drift), and an apply reinstalls from the pinned reference, where install-time verification enforces the locked identity and, on success, heals the stored bundle. A reinstall that fails verification lands inFailedwith the typed signature reason (exit 3).sync --adoptback-fills provenance from the stored bundle when one exists (post-verification installs); an install with no verifiable trust state requires the new--allow-unsignedflag (threaded through the API asallow_unsigned) and is recordedunsigned: true. Refusals classify asunsigned-rejected.Type of change
Test plan
task lint-fix, 0 issues)verifyStoredSignaturematrix (unsigned/no-provenance skip, missing-bundle fails closed for OCI but not git, delegation and failure propagation asserted against the mock); signature-failure-is-drift flow (check mode reportsDrifted, apply reinstalls and heals); adoption without verifiable trust fails withunsigned-rejectedand writes nothing, then recordsunsigned: truewith the flag.task docsregenerated (new--allow-unsignedsync flag + API field).Does this introduce a user-facing change?
Yes, behind the experimental gate:
sync --checknow fails when a stored signature no longer verifies, andsync --adoptrequires--allow-unsignedfor skills whose signature state cannot be established.Special notes for reviewers
Generated with Claude Code