stacklok / toolhive / 33511308889

70%

Build Type

push

github

Committed by web-flow

Commit Message

Verify key-signed skill installs against a public key (#6447)

* Encode and bound the pinned cosign public key

The lock file stores a pinned key as single-line base64 DER SPKI because
provenance values must be graphic and whitespace-free, so PEM armor cannot
be stored verbatim. Nothing converted between the two forms yet, and the
field shared the reference length bound, which is narrower than the key
material it now has to hold.

Add EncodePublicKey/DecodePublicKey as the single conversion between a
cosign.pub file and the stored form. Encoding refuses a private key by its
PEM label rather than by whatever a PKIX parse makes of its bytes: the
result is sent over the API and written to the lock file, and neither is
somewhere private material should reach by accident. Decoding re-validates
rather than trusting its input, since the value arrives from a request body
or a hand-editable file and is the artifact's only trust anchor.

Give publicKey its own bound: an RSA-4096 SPKI encodes to 736 characters,
so the 512 reference limit would reject a legitimate anchor rather than the
oversized garbage these limits exist to stop. Run the syntactic field checks
before the anchor's decode, so the length is bounded by a checked number
instead of the allocation being sized off an unchecked one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Signed-off-by: Samuele Verzi <samu@stacklok.com>

* Verify key-signed skill installs by public key

A skill pushed with `thv skill push --key` could be published but never
installed project-scoped: the keyless path has no trust root to chain a
key-pair signature to, and the signing key is recoverable from neither the
artifact nor its bundle, so nothing could supply the anchor. The previous
change made that refusal honest; this one gives it a way through.

Add `--public-key` to `thv skill install`, carried to the service as encoded
key material rather than as a path, since the server may be another process
o... (continued)

Coverage Stats

186 of 225 new or added lines in 9 files covered. (82.67%)

52 existing lines in 4 files now uncovered.

76644 of 109912 relevant lines covered (69.73%)

91.87 hits per line