Repository navigation
Clarify client workflow when no new metadata is available #235
Description
Activity
Thank you for the eagle eyed review. Apologies for not catching these when the changes were originally submitted.
Details per role
- For root there actually are instructions to just proceed with target downloading if no new root version is available from remote, according to the version in the unsigned filename, and to the version in the signed metadata. The latter means that filename and signed version are inconsistent, which seems like a repo error. Should that really be ignored? (cc @rdimitrov, #209)
Good observation, perhaps we should report an error here? Should a client be able to proceed to target downloading with trusted local metadata when there is such a repository error?
- For timestamp instructions where also added in #209. However, the new wording -- "In case they are equal, discard the new timestamp metadata and abort the update cycle. This is normal and it shouldn't raise any error." -- seems contradictory. Should this rather be -- "In case they are equal, discard the new timestamp metadata and go to 5.5"? (re-cc @rdimitrov)
Yes, you are absolutely right. We always download timestamp, if it hasn't changed versus what's on disk (version is the same) we should proceed with the version that's on disk.
- For snapshot and targets the instructions are to always download the version listed in timestamp (for snapshot) or snapshot (for targets) respectively. Would it be a fair optimization to only download, if the listed versions for either of them isn't already available locally?
Yes, I think so. If versions and hashes, where available, match what's already available locally there's no need to download.
Reacted by Lukas Pühringer
The client workflow describes in detail how to update metadata in order to download a target. However, it should be clarified how use local trusted metadata in order to download a target even if no new metadata is available from remote.
Details per role
For root there actually are instructions to just proceed with target downloading if no new root version is available from remote, according to the version in the unsigned filename, and to the version in the signed metadata. The latter means that filename and signed version are inconsistent, which seems like a repo error. Should that really be ignored? (cc @rdimitrov, #209)
For timestamp instructions were also added in #209. However, the new wording -- "In case they are equal, discard the new timestamp metadata and abort the update cycle. This is normal and it shouldn't raise any error." -- seems contradictory. Should this rather be -- "In case they are equal, discard the new timestamp metadata and go to 5.5"? (re-cc @rdimitrov)
For snapshot and targets the instructions are to always download the version listed in timestamp (for snapshot) or snapshot (for targets) respectively. Would it be a fair optimization to only download, if the listed versions for either of them isn't already available locally?