From 4d21e8a34c0e3766c226df440fd5f2306fa2db81 Mon Sep 17 00:00:00 2001 From: Joshua Lock Date: Wed, 5 Aug 2026 16:14:45 +0100 Subject: [PATCH 1/5] Only define THRESHOLD once GH-314 introduced a second definition of THRESHOLD _without_ a tag. There are two ways we can fix this: 1. introduce a second dfn tag and use a for attribute on each definition, i.e., 2. streamline to a single definition and update the DELEGATIONS definition to reference the THRESHOLD definition in the root section I've opted for 2 here as it's simpler and avoids redundant duplicate definitions. Signed-off-by: Joshua Lock --- tuf-spec.md | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 787dfcf..753643a 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -749,9 +749,11 @@ The "signed" portion of root.json is as follows: KEYID represented in this key list and in other files, only one unique key has that KEYID. - As before the THRESHOLD must be a positive integer number of keys (>=1) of - that role whose signatures are required in order to consider a file as being - properly signed by that role. + : THRESHOLD + A positive integer number of keys (>=1) of that role whose signatures are + required in order to consider a file as being properly signed by that role. + See the notes on THRESHOLD counting in the relevant steps of + [[#detailed-client-workflow]].
A root.json example file: @@ -1029,8 +1031,8 @@ format: } - KEYID and KEY are the same as is described for the - root.json file. + KEYID, KEY and THRESHOLD are the same as is + described for the root.json file. : ROLENAME :: @@ -1038,12 +1040,6 @@ format: The rolename MUST be unique in the delegations object: multiple roles with the same rolename are not allowed within a DELEGATIONS. - : THRESHOLD - :: - A positive integer number of keys (>=1) of that role whose signatures are required in - order to consider a file as being properly signed by that role. See the notes on - THRESHOLD counting in the relevant steps of [[#detailed-client-workflow]]. - : TERMINATING :: A boolean indicating whether subsequent delegations should be considered From 0c61aa6fa2d5964f5380ff995311637f7c2739d6 Mon Sep 17 00:00:00 2001 From: Joshua Lock Date: Wed, 5 Aug 2026 16:32:18 +0100 Subject: [PATCH 2/5] Fix warnings from latest bikeshed We have two definitions of KEYID and, by default, we get a random one at build time if the `for` attribute is not specified on the anchor () element. Squash randomness by always referring to the KEYID definition for the root role. Signed-off-by: Joshua Lock --- tuf-spec.md | 42 ++++++++++++++++++++++-------------------- 1 file changed, 22 insertions(+), 20 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 753643a..8160575 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1045,8 +1045,8 @@ format: A boolean indicating whether subsequent delegations should be considered if a matching target is not found in this delegation. - As explained in the [Diplomat paper - ](https://theupdateframework.io/papers/protect-community-repositories-nsdi2016.pdf), + As explained in the [Diplomat paper] + (https://theupdateframework.io/papers/protect-community-repositories-nsdi2016.pdf), terminating delegations instruct the client not to consider future trust statements that match this delegation's pattern, which stops the delegation processing once this delegation (and its descendants) have been processed. @@ -1335,9 +1335,10 @@ it in the next step. validated (version N+1). When computing the THRESHOLD each KEY MUST only contribute one SIGNATURE. That is, each SIGNATURE which is counted towards the THRESHOLD MUST have - a unique KEYID. Even if a KEYID is listed more than once in the - "signatures" list a client MUST NOT count more than one verified - SIGNATURE from that KEYID towards the THRESHOLD. + a unique KEYID. Even if a KEYID is listed + more than once in the "signatures" list a client MUST NOT count more than one + verified SIGNATURE from that KEYID towards the + THRESHOLD. If version N+1 is not signed as required, discard it, abort the update cycle, and report the signature failure. On the next update cycle, begin at step [[#update-root]] and version N of the root metadata file. @@ -1390,11 +1391,11 @@ it in the next step. in the trusted root metadata file. When computing the THRESHOLD each KEY MUST only contribute one SIGNATURE. That is, each SIGNATURE which is counted towards the THRESHOLD MUST have - a unique KEYID. Even if a KEYID is listed more than once in the - "signatures" list a client MUST NOT count more than one verified - SIGNATURE from that KEYID towards the THRESHOLD. If the - new timestamp metadata file is not properly signed, discard it, abort the - update cycle, and report the signature failure. + a unique KEYID. Even if a KEYID is listed + more than once in the "signatures" list a client MUST NOT count more than one + verified SIGNATURE from that KEYID towards the + THRESHOLD. If the new timestamp metadata file is not properly signed, + discard it, abort the update cycle, and report the signature failure. 3. **Check for a rollback attack.** @@ -1449,11 +1450,12 @@ it in the next step. the trusted root metadata file. When computing the THRESHOLD each KEY MUST only contribute one SIGNATURE. That is, each SIGNATURE which is counted towards the THRESHOLD MUST have - a unique KEYID. Even if a KEYID is listed more than once in the - "signatures" list a client MUST NOT count more than one verified - SIGNATURE from that KEYID towards the THRESHOLD. If the - new snapshot metadata file is not signed as required, discard it, abort the - update cycle, and report the signature failure. + a unique KEYID. Even if a KEYID is listed + more than once in the "signatures" list a client MUST NOT count more than one + verified SIGNATURE from that KEYID towards the + THRESHOLD. If the new snapshot metadata file is not signed as + required, discard it, abort the update cycle, and report the signature + failure. 4. **Check against timestamp role's snapshot version**. The version number of the new snapshot metadata file MUST match the version number listed @@ -1505,11 +1507,11 @@ it in the next step. in the trusted root metadata file. When computing the THRESHOLD each KEY MUST only contribute one SIGNATURE. That is, each SIGNATURE which is counted towards the THRESHOLD MUST have a - unique KEYID. Even if a KEYID is listed more than once in the - "signatures" list a client MUST NOT count more than one verified - SIGNATURE from that KEYID towards the THRESHOLD. If the - new targets metadata file is not signed as required, discard it, abort the - update cycle, and report the failure. + unique KEYID. Even if a KEYID is listed + more than once in the "signatures" list a client MUST NOT count more than one + verified SIGNATURE from that KEYID towards the + THRESHOLD. If the new targets metadata file is not signed as + required, discard it, abort the update cycle, and report the failure. 4. **Check against snapshot role's targets version**. The version number of the new targets metadata file MUST match the version number listed From 8eaf5ad8a30e47fd18f482d0bc49be9e61e290c8 Mon Sep 17 00:00:00 2001 From: Joshua Lock Date: Wed, 5 Aug 2026 16:33:10 +0100 Subject: [PATCH 3/5] Pin the bikeshed version we use in workflows This will prevent bikeshed releases unintentionally breaking our builds without anyone noticing until a CI workflow with additional changes is run. Signed-off-by: Joshua Lock --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 7b706bb..6e9b092 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1 +1 @@ -bikeshed \ No newline at end of file +bikeshed==7.1.1 From 1db0deb68a5c852d9655876b7cbc616e781e06c6 Mon Sep 17 00:00:00 2001 From: Joshua Lock Date: Wed, 5 Aug 2026 16:33:38 +0100 Subject: [PATCH 4/5] Update Joshua's affiliation Changed role, updating affiliation Signed-off-by: Joshua Lock --- tuf-spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tuf-spec.md b/tuf-spec.md index 8160575..a2289aa 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -6,7 +6,7 @@ Abstract: A framework for securing software update systems. Date: 2026-07-15 Editor: Justin Cappos, NYU Editor: Trishank Karthik Kuppusamy, Apple -Editor: Joshua Lock, Verizon +Editor: Joshua Lock, University of Lincoln Editor: Marina Moore, Edera Editor: Lukas Pühringer, Eclipse Repository: theupdateframework/specification From b6621967f6b5a917bd8335ca54cf48630912e4ac Mon Sep 17 00:00:00 2001 From: Joshua Lock Date: Wed, 5 Aug 2026 16:33:55 +0100 Subject: [PATCH 5/5] Bump Version and Date for this PR Signed-off-by: Joshua Lock --- tuf-spec.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index a2289aa..9f9d8f3 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -3,7 +3,7 @@ Title: The Update Framework Specification Shortname: TUF Status: LS Abstract: A framework for securing software update systems. -Date: 2026-07-15 +Date: 2026-08-05 Editor: Justin Cappos, NYU Editor: Trishank Karthik Kuppusamy, Apple Editor: Joshua Lock, University of Lincoln @@ -16,7 +16,7 @@ Boilerplate: copyright no, conformance no Local Boilerplate: header yes Markup Shorthands: css no, markdown yes Metadata Include: This version off, Abstract off -Text Macro: VERSION 1.0.35 +Text Macro: VERSION 1.0.36 Note: We strive to make the specification easy to implement, so if you come