TUF Terminating Delegations Must Be Tested as a Trust Decision
The Update Framework protects software update metadata with separate root, targets, snapshot, and timestamp roles. The targets role can delegate responsibility for a subset of paths to other roles. A delegation includes the role's keys, threshold, path patterns, and a terminating flag.
That flag is not a performance hint. The TUF specification says a terminating delegation tells the client not to consider subsequent trust statements that match the delegation's pattern if a target is not found in that delegation or its descendants. The value changes which role may speak for a package when several delegation patterns overlap.
Overlap is the hard case
A repository can delegate bar-* to one role and all paths to another. An attacker who can choose an unexpected ordering or a broad delegation can change which role is considered authoritative. TUF addresses this with ordered delegation processing, path restrictions, thresholds, and terminating semantics. The client must check that a target is in one of the trusted paths of every role in the delegation chain, not just in the path of the role that directly names the target.
The implementation risk is usually in integration code. A client may load several targets metadata files, sort them by role name, or merge results from multiple delegations. That behavior can turn a terminating delegation into a suggestion. The correct rule is to follow the signed delegation order, stop where the metadata says to stop, and fail closed on an unresolved or ambiguous match.
Role names need uniqueness inside a delegations object. Keys need the expected role, threshold, and validity. A revoked delegation should disappear from newly signed metadata, but clients may still need to verify the metadata version and expiration before deciding that the old statement is gone. A delegation is trusted only through a valid chain rooted in the trusted root metadata.
Test the decision, not just the signature
A useful test suite includes a target that matches no delegation, a target that matches one terminating delegation, and a target that matches both a terminating delegation and a later broad delegation. The last case should produce a deterministic rejection or an authoritative result from the permitted role. Run the same test after rotating a key, after removing a delegation, and after changing the path pattern.
Test an expired targets file, a snapshot that references an older version, and a metadata file signed by the wrong role. These cases should not fall back to a cached artifact just because the artifact hash matches. The repository's update policy must state what it does when metadata cannot be verified and whether the application may continue with the last trusted version.
Keep the policy auditable
Store the delegation graph with the release metadata. Record which role owns each package path, the key IDs, the threshold, and the terminating decision. Review changes to that graph as security changes, even when the package bytes have not changed. A new delegation can make an old signed package unreachable or make a different signer authoritative.
TUF is designed to make trust explicit. Terminating delegations are one of the places where that design becomes a runtime policy. If the client processes them as ordinary search results, the metadata can be valid while the authorization decision is wrong.
Top comments (0)