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 diff --git a/tuf-spec.md b/tuf-spec.md index 787dfcf..9f9d8f3 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -3,10 +3,10 @@ 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, Verizon +Editor: Joshua Lock, University of Lincoln Editor: Marina Moore, Edera Editor: Lukas Pühringer, Eclipse Repository: theupdateframework/specification @@ -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 @@ -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,19 +1040,13 @@ 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 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. @@ -1339,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. @@ -1394,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.** @@ -1453,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 @@ -1509,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