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 fetching targets with multiple hashes if one is missing #199

Open
erickt opened this issue Dec 23, 2021 · 4 comments
Open

Clarify fetching targets with multiple hashes if one is missing #199

erickt opened this issue Dec 23, 2021 · 4 comments

Comments

@erickt
Copy link
Contributor

erickt commented Dec 23, 2021

In https://theupdateframework.github.io/specification/v1.0.26/#fetch-target, when downloading targets with consistent snapshots enabled, it states:

... Otherwise, the filename is of the form HASH.FILENAME.EXT (e.g., c14aeb4ac9f4a8fc0d83d12482b9197452f6adf3eb710e3b1e2b79e8d14cb681.foobar.tar.gz), where HASH is one of the hashes of the targets file listed in the targets metadata file found earlier in step § 5.6 Update the targets role. In either case, the client MUST write the file to non-volatile storage as FILENAME.EXT.

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.

@mnm678
Copy link
Collaborator

mnm678 commented Jan 3, 2022

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?

@trishankatdatadog
Copy link
Member

I think it makes sense to try all of the hashes before giving up, similar to the behavior of go-tuf.

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.)

@lukpueh
Copy link
Member

lukpueh commented Jan 11, 2022

Cross-referencing related general issue #198

@lukpueh
Copy link
Member

lukpueh commented Jan 11, 2022

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.

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

No branches or pull requests

4 participants