Spec doesn't say what happens to locally cached files when root metadata is changed

[edsko]

In theupdateframework/specification#76 I mention that we delete the cached snapshot and timestamp on a verification error to avoid attacks where the attackers sets the file version to MAX_INT. However, we now think that the cached snapshot should be deleted whenever the root info is updated:

If during the normal update process we notice that the root info was updated (because the hash of root.json in the new snapshot is different from the old snapshot) we download new root info and start over, without (yet) downloading a (potential) new index. This means it is important that we not overwrite our local cached snapshot, because if we did we would then on the next iteration conclude there were no updates and we would fail to notice that we should have updated the index. However, unless we do something, this means that we would conclude on the next iteration once again that the root info has changed (because the hash in the new shapshot still doesn't match the hash in the cached snapshot), and we would loop.

[dcoutts]

Clarification: the "index" here is simply a file mentioned in the snapshot.json.

Our adaptation of TUF for Hackage involves us putting all the package metadata (including targets.json and other delegated target stuff) inside one big index.tar file, rather than downloading all these bits individually. So our snapshot.json only lists root.json and index.tar. The rest lives inside index.tar. (The index.tar is updated incrementally, and uses compression)

[edsko]

Ah, yes, sorry, I thought I had removed all stuff specific to our implementation. The general point stands though: "we would fail to notice that we should have updated any other file mentioned in the snapshot".