-
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
Clarify fetching targets with multiple hashes if one is missing #199
Comments
I think it makes sense to try all of the hashes before giving up, similar to the behavior of go-tuf. It looks like the python-tuf ng client only uses the first hash, and the legacy python-tuf client uses only the last hash. Regardless, we should update this text to make it more clear what the expected behavior is. What do others think the expected behavior should be? |
Great question, and I agree to this answer. That also means clarifying how the server should write consistent targets. (Use one or all of the hashes? To me one is enough.) |
Cross-referencing related general issue #198 |
Good question indeed! I somehow lean towards putting the onus on the server/repo to "duplicate" the files for all supported hashes (or rather just provide the corresponding redirects), so that the client can access the file using any of the hashes as prefix. This makes the client code simpler and potentially reduces client requests. |
In https://theupdateframework.github.io/specification/v1.0.26/#fetch-target, when downloading targets with consistent snapshots enabled, it states:
Consider the case where we have a consistent snapshot repository, and a target
foo
with both sha-256 and sha-512 hashes listed. As written, it sounds like we we pick one of the entries, say the sha-256 and fetch$SHA256.foo
, but it doesn't exist. As written, it sounds like we should give up, but$SHA512.foo
might exist. Should we try to download it as well? go-tuf, for example, will try to download every hash prefixed version.The text was updated successfully, but these errors were encountered: