Tags: theupdateframework/specification
Tags
Update TUF threshold information and editor details (#314) * Update TUF threshold information and editor details I'm proposing a patch spec update to make it clearer that a threshold of 0 (or less) is not allowed. See: GHSA-fphv-w9fq-2525 for more details. I've also updated people's affiliation and suggested that slack is the best way to contact us. Signed-off-by: Justin Cappos <justincappos@gmail.com> * Update tuf-spec.md Co-authored-by: Lukas Pühringer <luk.puehringer@gmail.com> Signed-off-by: Justin Cappos <justincappos@gmail.com> * Demote THRESHOLD "definition tag" in tuf-spec.md to fix lint Signed-off-by: Justin Cappos <justincappos@gmail.com> --------- Signed-off-by: Justin Cappos <justincappos@gmail.com> Co-authored-by: Lukas Pühringer <luk.puehringer@gmail.com>
Add more text describing threshold computation (#154) * Add signature threshold computation advice Several implementations have made similar errors -- counting multiple signatures by the same keyid -- when implementing signature threshold computation, for example the reference implementation: GHSA-pwqf-9h7j-7mv8 theupdateframework/python-tuf@83ac7be Add some extra description to the detailed client workflow to further explain that a threshold of signatures should only count one signature per key. Signed-off-by: Joshua Lock <jlock@vmware.com> * Recommend signatures only contain one sig per keyid In an attempt to help implementers protect against incorrect threshold computation, update "File formats" to suggest that the signatures list contain only a single signature per keyid at metadata creation time. Suggested-by: Jussi Kukkonen <jkukkonen@vmware.com> Signed-off-by: Joshua Lock <jlock@vmware.com> * Address review comments Be more explicit that each KEYID can only count one signature towards the threshold. Signed-off-by: Joshua Lock <joshuagloe@gmail.com> * Bump version and date Signed-off-by: Joshua Lock <joshuagloe@gmail.com> --------- Signed-off-by: Joshua Lock <jlock@vmware.com> Signed-off-by: Joshua Lock <joshuagloe@gmail.com>
Clone repository before setting up Python (#250) Since 70f167f the setup-python action restores a cache based on the fingerprint of requirements.txt, therefore we must ensure a copy of that file exists before we setup Python. This order of events requires the first action to be checkout to clone the repository. Signed-off-by: Joshua Lock <jlock@vmware.com> Signed-off-by: Joshua Lock <jlock@vmware.com>
Update metadata version comparison rules in client workflow (#209) * Update metadata version comparison rules in client workflow The client workflow has a set of version comparison rules for how to update metadata files. The following PR addresses the differences coming from the fact that when updating not all metadata files should be treated equally. Fixes #207 and is related to #114 Signed-off-by: Radoslav Dimitrov <dimitrovr@vmware.com> * Bump date and version to 1.0.29 Signed-off-by: Radoslav Dimitrov <dimitrovr@vmware.com> * Address what happens in case of equal metadata versions for client update Signed-off-by: Radoslav Dimitrov <dimitrovr@vmware.com> * Update VERSION and Date Co-authored-by: Joshua Lock <jlock@vmware.com>
Remove ambiguity in update root after a failed attempt (#196) In section 5.3. Update the root role the specification suggests, in multiple steps (5.3.4, 5.3.5 and 5.3.10) that should the client fail to verify the updated root metadata the downloaded data should be discarded, the error reported, and: > On the next update cycle, begin at step § 5.3 Update the root role and > version N of the root metadata file. This directive only makes sense if the client application continues running between update cycles and therefore still has initial trusted root metadata loaded and a fixed update start time recorded. For at least python-tuf and go-tuf this is not how the update workflow is implementated. Avoid confusion by removing the recommendation to start at 5.3 on the next update cycle and instead leave only the suggestion to remove unverified data. Logically, the next update cycle starts at the first step -- loading the initial trusted root metadata. Signed-off-by: Joshua Lock <jlock@vmware.com>
A round of clean-up/clarifications (#195) * Capitalise TAP consistently * Clarify that mirrors are optional * Bump Date and VERSION after edits * Apply suggestions from code review * Note consistent snapshot requirements in "3.1. Repository layout" Briefly describe the requirement for unique identification of files for consistent snapshots and cross-link to "6.2. Consistent snapshots" for more information. Signed-off-by: Joshua Lock <jlock@vmware.com> Co-authored-by: lukpueh <luk.puehringer@gmail.com>
Clean up "Writing consistent snapshots" section (#187) * Match how metadata and target filenames are referred to in the detailed client workflow, i.e. filename.ext -> FILENAME.EXT * Remove suggestion to write a version of the root metadata without a version prefix. We only ever look for version-prefixed version of root metadata. * More use of RFC-2119 keywords to clarify repository handling of consistent snapshots * Link to CONSISTENT_SNAPSHOT attribute definition * Clarify that all versions of root metadata MUST be kept for outdated clients to be able to update Signed-off-by: Joshua Lock <jlock@vmware.com> Co-authored-by: lukpueh <luk.puehringer@gmail.com> Co-authored-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>
Explain why we check hashes before signatures (#142) * explain why we check hashes before signatures Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com> bump version * Update tuf-spec.md Co-authored-by: Joshua Lock <jlock@vmware.com> * Update tuf-spec.md Co-authored-by: Joshua Lock <jlock@vmware.com> Co-authored-by: Joshua Lock <jlock@vmware.com>
PreviousNext
