Conversation
Signed-off-by: Asra Ali <asraa@google.com>
|
cc'ing reviewers, please check my on my TUF logic. @trishankatdatadog |
Seems right to me, yes. If there is a delegatee you want to delete, you should delete:
But keep the snapshot metadata about (2) around until timestamp/snapshot needs to be reset (e.g., due to a fast-forward attack, as described in Section 5.3.11 of the spec). (3) can safely be updated in the snapshot metadata so long as it doesn't rollback itself. Any disagreements @mnm678 @JustinCappos? |
Thank you for this list! I double checked that there weren't any delegatee targets as well. Those were removed.
+1, the snapshot will hold on to the delegations indefinitely (until we refresh keys). double-checked that our automation won't remove it. |
joshuagl
left a comment
There was a problem hiding this comment.
LGTM! Thanks for the detailed review @trishankatdatadog
Signed-off-by: Asra Ali asraa@google.com
Fixes #545
The sync job checks to make sure that none of the files uploaded are expired. Our unused delegated targets files just expired which caused the sync job to fail. We can safely remove the target files, so long as the snapshot.json continues to hold their hashes to prevent a rollback attack.
When we snapshot, we preserve old delegated targets files hashes and versions.
When we rotate snapshot keys, we should clear the snapshot.json of the old unused delegations.
Summary
Release Note
Documentation