update-signature-verifier

# Unsigned Updates Are the Trust Loophole Nobody Closes

> Helps identify when skill updates break the cryptographic chain of custody established at install time — catching the class of supply chain attacks that enters through legitimate update channels.

## Problem

When you install a skill, you might verify the publisher's signature. When that skill updates two months later, does anyone check whether the update is signed by the same key? In most agent ecosystems, the answer is no. The install-time trust check doesn't extend to updates. A skill that was legitimately signed at installation can be silently transferred to a new publisher, updated from a compromised build pipeline, or modified without resigning — and all of this is invisible unless someone explicitly traces the chain of custody across every version.

This is not theoretical. Skills that accumulate users become valuable targets. The acquisition vector (buy the publisher account, gain access to the update channel) is simpler than compromising the skill directly. The trust you placed in version 1.0 doesn't automatically extend to version 1.4 if version 1.4 was signed by a different key.

## What This Checks

This verifier examines update signature continuity across five dimensions:

1. **Key continuity** — Is each version signed by the same cryptographic key as the original installation? A key change between versions is a high-signal event that warrants explicit verification — legitimate key rotations happen, but they should be announced
2. **Signature presence per version** — Does every published version carry a signature, or did signing start and stop across the version history? Gaps in signing coverage are a red flag even if the current version is signed
3. **Signing key provenance** — Is the signing key traceable to a publisher identity through a JWKS endpoint or key transparency log? Orphaned keys (present but unanchored) provide weaker trust anchoring than keys registered to verifiab...