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

client: hashes and length should be optional in (timestamp, snapshot) METAFILEs #771

Open
jku opened this issue Jun 5, 2024 · 5 comments

Comments

@jku
Copy link

jku commented Jun 5, 2024

I was sure this issue already existed but now I cannot find it...

tough client does not seem to support METAFILEs without hashes or length within timestamp and snapshot metadata.

The specification is clear in this case: these are optional fields that can be omitted:

LENGTH
An integer length in bytes of the metadata file at METAPATH. It is OPTIONAL and can be omitted to reduce the snapshot metadata file size. In that case the client MUST use a custom download limit for the listed metadata.

HASHES
A dictionary that specifies one or more hashes of the metadata file at METAPATH, with the cryptographic hash function as key and the value as HASH, the hexdigest of the cryptographic function computed on the metadata file at METAPATH. For example: { "sha256": HASH, ... }. HASHES is OPTIONAL and can be omitted to reduce the snapshot metadata file size. In that case the repository MUST guarantee that VERSION alone unambiguously identifies the metadata at METAPATH.

I am currently not including these fields in what is likely to be sigstore TUF repository in future. This lead to sigstore/sigstore-rs#369

@flavio
Copy link
Contributor

flavio commented Jun 28, 2024

I'm willing to look into that and eventually build a patch for that. I tried to reproduce the issue you mentioned using the sigstore-staging TUF repository, but this is currently malformed (as you pointed out inside of the sigstore-rs issue).

I've looked into tough and I think METAPATH is handled by SnapshotMeta. This one has both length and hashes optional. Everything seems to be fine 🤔

I'll look more into that once I'm able to reproduce the issue

@jku
Copy link
Author

jku commented Jul 1, 2024

huh! I can make a test repo for this tomorrow -- it's of course possible I'm somehow mistaken

@jku
Copy link
Author

jku commented Jul 1, 2024

Actually there is a test repo:

$ curl -o root.json https://jku.github.io/tuf-demo/metadata/3.root.json
$ tuftool download --root root.json -m https://jku.github.io/tuf-demo/metadata/ -t https://jku.github.io/tuf-demo/targets -n file1.txt out/
Failed to load repository: Failed to parse timestamp metadata: missing field `length` at line 14 column 4

So I suppose the issue might be only with timestamps METAFILE?

flavio added a commit to flavio/tough that referenced this issue Jul 1, 2024
According to the TUF specification, the `meta` attribute of
`timestamp.json` must follow the same specification of `METAFILES`.
That means it has optional `LENGTH` and `HASHES`.

See [this](https://theupdateframework.github.io/specification/latest/#file-formats-timestamp) section of
the TUF specification.

Fixes issue awslabs#771

Signed-off-by: Flavio Castelli <fcastelli@suse.com>
@flavio
Copy link
Contributor

flavio commented Jul 1, 2024

@jku thanks for the reproducer. The problem was indeed with how timestamp.json was parsed. I've created #778 to address that. With these changes I can download your test TUF repository.

I hope someone from the TUF maintainers will take a look at that PR

@jpculp
Copy link
Contributor

jpculp commented Jul 2, 2024

Thank you @jku for raising this issue and thank you @flavio for addressing it! Sorry we didn't catch this sooner.

flavio added a commit to flavio/tough that referenced this issue Aug 8, 2024
According to the TUF specification, the `meta` attribute of
`timestamp.json` must follow the same specification of `METAFILES`.
That means it has optional `LENGTH` and `HASHES`.

See [this](https://theupdateframework.github.io/specification/latest/#file-formats-timestamp) section of
the TUF specification.

Fixes issue awslabs#771

Signed-off-by: Flavio Castelli <fcastelli@suse.com>
SequeI pushed a commit to securesign/tough that referenced this issue Aug 20, 2024
According to the TUF specification, the `meta` attribute of
`timestamp.json` must follow the same specification of `METAFILES`.
That means it has optional `LENGTH` and `HASHES`.

See [this](https://theupdateframework.github.io/specification/latest/#file-formats-timestamp) section of
the TUF specification.

Fixes issue awslabs#771

Signed-off-by: Flavio Castelli <fcastelli@suse.com>
SequeI added a commit to securesign/tough that referenced this issue Aug 22, 2024
* Bump rust to 1.78.0 in actions runner

Also addressed new clippy warnings.

* Bump cargo-deny in Makefile

* Bump rust to stable in actions runner

Also addressed new clippy warnings.

* Update rust dependencies

Also updated `deny.toml`.

* fix: timestamp.json meta can has optional fields

According to the TUF specification, the `meta` attribute of
`timestamp.json` must follow the same specification of `METAFILES`.
That means it has optional `LENGTH` and `HASHES`.

See [this](https://theupdateframework.github.io/specification/latest/#file-formats-timestamp) section of
the TUF specification.

Fixes issue awslabs#771

Signed-off-by: Flavio Castelli <fcastelli@suse.com>

---------

Signed-off-by: Flavio Castelli <fcastelli@suse.com>
Co-authored-by: Patrick J.P. Culp <jpculp@amazon.com>
Co-authored-by: Flavio Castelli <fcastelli@suse.com>
flavio added a commit to flavio/tough that referenced this issue Sep 4, 2024
According to the TUF specification, the `meta` attribute of
`timestamp.json` must follow the same specification of `METAFILES`.
That means it has optional `LENGTH` and `HASHES`.

See [this](https://theupdateframework.github.io/specification/latest/#file-formats-timestamp) section of
the TUF specification.

Fixes issue awslabs#771

Signed-off-by: Flavio Castelli <fcastelli@suse.com>
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

3 participants