stacklok / toolhive / 32973771746

71%

Build Type

push

github

Committed by web-flow

Commit Message

Re-verify stored plugin signatures during sync (#6399)

* Re-verify stored plugin signatures during sync

Plugin 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. 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 signature lives on the commit and is 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 and Go client DTOs), recorded as unsigned in the
entry.

Part of #6300. Mirrors #6131 for skills.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Samuele Verzi <samu@stacklok.com>

* Bound stored plugin signature material

The Sigstore bundle persisted with an install and the commit payload and
gitsign signature a git install verifies are all attacker-influenced and
unbounded at their source: a registry serves whatever bundle it likes,
and git imposes no length limit on a commit message. Without a ceiling a
hostile plugin source can push a multi-MB blob into SQLite on every
install, which every subsequent sync then reads back for offline
re-verification.

Cap all three at capture time in verify.go, before the bytes reach
InstallOptions and the store, and reject rather than truncate — a
truncated bundle would fail to verify later and be indistinguishable
from tampering. The git payload and signature are checked before ... (continued)

Coverage Stats

75 of 81 new or added lines in 5 files covered. (92.59%)

6 existing lines in 3 files now uncovered.

75457 of 108625 relevant lines covered (69.47%)

89.62 hits per line