Display recorded trust state to the user - #6137
Draft
samuv wants to merge 1 commit into
Draft
Conversation
RFC THV-0080 wants the identity pinned at trust-on-first-use displayed prominently, not discovered weeks later inside a signer-mismatch error. ProvenanceInfo becomes part of API responses: install results carry the provenance or unsigned exception that was just recorded (the CLI prints it — a deliberate exception to silent success, since a recorded trust anchor is security-relevant information, not progress chatter), and skill info surfaces the lock file's recorded trust state for project-scoped skills, provisional markers included. Part of #5899. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## skills-sig/13-upgrade-guard #6137 +/- ##
===============================================================
- Coverage 72.47% 72.46% -0.02%
===============================================================
Files 740 739 -1
Lines 76358 76319 -39
===============================================================
- Hits 55344 55306 -38
+ Misses 17083 17074 -9
- Partials 3931 3939 +8 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
5 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, on top of #6132. This is the display follow-up promised in #6129's review.
Summary
RFC THV-0080 requires the identity pinned at trust-on-first-use to be "displayed prominently" — today the user first meets it weeks later inside a
signer-mismatch403. This PR surfaces the recorded trust state everywhere it's decided or queried:ProvenanceInfobecomes API-visible (signer_identity,cert_issuer,repository_uri,sigstore_url,provisional) instead ofjson:"-"end to end.provenanceorunsigned, and the CLI prints it —Installed <name> (signed by <identity>), the provisional variant, or the explicit-unsigned variant.thv skill infoshows the lock file's recorded trust state for project-scoped, lock-managed skills (Signed by:/Cert issuer:/ unsigned-exception lines, JSON included).Type of change
Test plan
task lint-fix, 0 issues)installAndRegisternow surfaces it on the result);task docsregenerated (swagger for the new response fields).Does this introduce a user-facing change?
Yes, behind the experimental gate: successful project-scoped installs print the recorded trust state, and
thv skill infoshows the pinned signer identity.Special notes for reviewers
.claude/rules/cli-commands.md): a freshly pinned trust anchor is security-relevant information the RFC requires to be visible, not progress chatter. Happy to gate it differently if you disagree.Generated with Claude Code