Skip to content
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

Clarify client workflow when no new metadata is available #235

Open
lukpueh opened this issue Jun 13, 2022 · 1 comment
Open

Clarify client workflow when no new metadata is available #235

lukpueh opened this issue Jun 13, 2022 · 1 comment

Comments

@lukpueh
Copy link
Member

lukpueh commented Jun 13, 2022

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?

@joshuagl
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants