You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: