-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Describe and delineate "trusted metadata" #179
Comments
When/how trusted metadata is loaded for non-root roles is also not part of the current specification. |
My current thinking is that we should define two levels of trusted metadata:
Then we use these definitions so that we allow "trusted in the interim" metadata to be
but "trusted in the interim" metadata can never be used to progress to the workflow for "next" metadata: we cannot do targets validation before we have a "fully trusted" snapshot. I think a definition like that makes defining the "load trusted local metadata" and "rollback checks" steps fairly easy, or at least possible? Something that might not be trivial is deciding when to do those steps: I've been involved with ngclient so I think trusted metadata should only be loaded once the "previous" metadata is "fully trusted" -- in other words before we can load local snapshot, we should have updated root and timestamp through their full workflows, aka they should be "fully trusted". I can see how there are other viewpoints considering the legacy updater does not work like this :) but I also don't want the spec to prevent me from doing the process I mention above as I consider it correct (as it prevents loading local metadata that is no longer signed by current threshold of current keys) and easier to implement without bugs. |
Just to document the issues with rollback checks: the intent seems to be that
None of these are explicitly mentioned in the spec. I'll include the last one for completeness, but this one is in the spec:
|
The detailed client workflow refers to trusted metadata, or a specific role's trusted metadata, several times. However, it doesn't explain what trusted metadata is, except implicitly during 5.3.7 where we "Set the trusted root metadata file".
This is particularly surprising when discussing the use of trusted metadata when checking for rollback attacks in 5.4.3 and 5.5.5
Furthermore, we should explicitly refer to the initial trusted root metadata that is loaded in 5.2 by a distinct name. This metadata that is delivered out-of-band should be lifecycle managed differently to other trusted metadata and a distinct name makes it easier to discuss in ancillary materials.
The text was updated successfully, but these errors were encountered: