How should we handle metadata that has the same version but different content?

[erickt]

The spec is a little vague as to how we should handle updating metadata that shares the same version number as the trusted metadata, but has different content. We can encounter this situation in two cases:

• When we fetch a new timestamp, section 5.2.2 says it's okay if the new file shares the same version as the trusted version. However, it doesn't say what we should do if this new file points at a different snapshot than the trusted timestamp.
• When we fetch a target or delegated target, section 4.4.4 states it's optional for the snapshot role to contain hashes of the targets and delegated targets. Without hashes, we have no way to tell without downloading the file to see if it matches the trusted version, nor what we should do if it doesn't match.

I can think of a few possible ways we could extend the spec to cover these situations:

• Just trust the new file (this though would probably expose us to all sorts of weird issues).
• Always try to download metadata, even if we think we have that version locally. Check that the new file matches our trusted content, or fail the update.
• Implement the above test for timestamp updates, but instead in section 5.4, change the logic to skip fetching any metadata version if we already trust that version (and hash if it's listed in the trusted snapshot).

[rdimitrov]

@erickt - Hey, I think #209 partially covered the topics of this issue, at least in regards to the timestamp update process. Are the rest of the thoughts still relevant or perhaps we can close this one?

[trishankatdatadog]

@erickt - Hey, I think #209 partially covered the topics of this issue, at least in regards to the timestamp update process. Are the rest of the thoughts still relevant or perhaps we can close this one?

I don't think we can close this yet. Erick does raise some interesting questions. Now, it's not clear to me why a correct repository would do this, but a buggy/compromised/malicious one might. To me, the safest option is for clients to fail the update process, and buggy/compromised repositories can take action to recover so that clients can update again.

Erick, WDYT?