Decide how to handle corrupt local metadata

tuf::Client will currently error out on create if a fetch of root metadata from the local repository fails with any error other than Error::NotFound. The implementation could attempt to fetch the metadata from the remote repository in these error cases and re-store the metadata to the local repository, allowing the tuf::Client to recover from on-disk metadata corruption. However, such an implementation may allow an attacker to intentionally force a tuf::Client to sync an older root.json (or even a forked root.json if keys were compromised).

Is it better to stop taking updates if local root metadata is corrupt or potentially allow a man-in-the-middle if root keys between the static trusted version and head were compromised and an attacker has the ability to both corrupt local root metadata and serve their own root metadata?

Start by reviewing the tuf::Client creation path and how it fetches root metadata from local and remote repositories. Compare recovery from corrupt local metadata with the risk of accepting an older or forked root.json. Done means reaching and documenting a clear policy for whether corruption stops updates or permits verified recovery.