Immediate Issue Summary

If the client concludes that its snapshot version is out of date (i.e. it has validated a new timestamp version that lists a snapshot version newer than the one it currently has and trusts), it tries to fetch the new snapshot version. If that fails (can't get snapshot or snapshot can't be validated), then the previously trusted known-to-be-outdated snapshot metadata is deleted, both on disk and in memory. This is correct behavior per the spec. Unfortunately, the in-memory deletion of the snapshot metadata stored in roledb results in an error on any further attempts to update snapshot (see below).

Credit goes to Allen Cain (@eacain) for finding this issue.

Diagnosis

There is a bug in TUF in the functioning of tuf.sig.verify / tuf.roledb. In this bug, the keys expected to sign for role X (snapshot in this case) are stored in the roledb entry for role X. (In this case, tuf.sig.verify expects to find the keys expected of valid snapshot metadata in roledb's entry for snapshot, not root.) While this information is still updated based only on validated root metadata, this implementation remains wrong for a few reasons. The issue here is that role X may be deleted if a new version fails to validate and it is known that the current version is outdated (as correctly occurs in this case); while that's fine, the implementation cannot continue to expect to find the keys in the deleted entry. These keys come from the delegating role (root in this case), and they should be checked against information indexed by the delegating role, not indexed against the delegated role. This behavior is also related to a known issue (#660) that can cause difficulties if multiple roles delegate to the same delegated Targets role. Other solutions to the issue identified here include changing the role removal code to leave the expected keys cached there from the delegating role; this, however is not advisable as it is somewhat counter-intuitive and might lead to flawed implementation or odd edge cases (similar to this one).

In short, the information should be indexed by delegating role, not by delegated role, solving both of these issues. This issue derives from issue #660, so see that for the broader explanation of the more general issue.