The Update Framework (TUF)

The Update Framework (TUF) starts from an assumption most signing schemes avoid: that the repository will eventually be compromised. Rather than asking how to prevent that, it asks what an update client can still guarantee afterwards — and answers with a set of separate signing roles, expiring metadata, and threshold signatures arranged so that stealing any one key is not enough to push a malicious update.

• Separated roles - Root, targets, snapshot and timestamp metadata, each signed independently and each with a different blast radius.
• Threshold signatures and key rotation - No single key is sufficient, and rotation is part of the design rather than an incident response.
• Freeze and rollback protection - Expiring metadata, so an attacker cannot hold a client at a known-vulnerable version by simply withholding updates.
• Defined JSON metadata - Machine-readable, and the basis for adaptations including Notary and PyPI’s work.

TUF is the oldest specification in this part of the catalog and the one most often reinvented badly. Anywhere an API platform distributes something a client will execute — SDKs, plugins, agents, gateway modules, MCP servers — the update channel is a supply-chain surface with exactly the compromise model TUF was designed for. It underpins the Notary Project lineage and complements Sigstore, which solves key management from the other direction with short-lived certificates instead of long-lived roles.