Open nexustar opened 2 years ago
Hi @nexustar, thank you for taking the time to file this issue.
Historically TUF did work this way: root metadata was listed as a METAFILE
in the meta
field of the snapshot metadata and would only be fetched if snapshot indicated the root role had changed. When root had changed, the client would then restart the update process with the new root metadata.
This behaviour was changed to improve TUF's compromise resilience (and, I think, simplifies implementation of the client workflow). Signing keys for the snapshot role are often kept online or used in an automated fashion. With the old TUF behaviour, if the snapshot role was compromised an attacker may choose to continue to list old versions of the root metadata in snapshot which could refer to the compromised snapshot key as being valid (at least until such time as the old root metadata expires).
Unfortunately, tracking the full history of when this change was introduced is difficult. The earliest references I could find are:
At beginning of update, TUF client try to update root role,but most of time there is no update of root role. For a check for updates step, at lease 2 download is needed (n+1.root.json and timestamp.json if there is no update) if record version of root role in snapshot role, we can fetch timestamp role first, and update it when timestamp role changed and snapshot say it need to update. On security way, I think it is the same because if the attacker can return fake snapshot,he also can pretend that there is no n+1 version of root role