Skip to content

Make length and hashes optional in snapshot/timestamp metadata #996

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

Closed
lukpueh opened this issue Mar 11, 2020 · 6 comments
Closed

Make length and hashes optional in snapshot/timestamp metadata #996

lukpueh opened this issue Mar 11, 2020 · 6 comments

Comments

@lukpueh
Copy link
Member

lukpueh commented Mar 11, 2020

Description of issue or feature request:

As per the specification (v1.0.1) length and hashes fields in timestamp and snapshot metadata are optional. The reference implementation should reflect this.

Current behavior:

  • timestamp metadata always includes length and hashes of snapshot metadata (see reposoitory_lib.generate_timestamp_metadata)
  • snapshot metadata always excludes length and hashes of (delegated) targets metadata (see repository_lib.generate_snapshot_metadata)

Expected behavior:
Add option to include/exclude these fields in the relevant functions in repository_lib. Since these functions are usually called via write/writeall the option should be made available there too. It's also conceivable to configure this via attributes on the Repository object.

@MVrachev
Copy link
Collaborator

I will work on that issue.

I have one question though: I am planning to add additional parameters to generate_timestamp_metadata and generate_snapshot_metadata which will be used to decide whenever hashes and length should be used, but my question is what should be their default value?

@lukpueh
Copy link
Member Author

lukpueh commented Apr 16, 2020

what should be their default value?

I suggest to choose them so that the default behavior of these functions matches their current behavior.

@joshuagl
Copy link
Member

My initial feeling was that we should default to the current behaviour, but I wonder whether there's an argument to be made for not providing default values. If we don't have default values, we force implementers to explicitly choose whether they want to include lengths and hashes, rather than inheriting a default.

Furthermore I think the specification suggesting the fields are optional implies that they would not be included by default, and thus would expect similar behaviour from a reference implementation.

Conversely, I think the current values probably are sensible defaults, particularly for i.e. the PEP 458 implementation. I'm curious to read what others think.

@MVrachev
Copy link
Collaborator

I feel like security by default should be implied here and use length and hashes fields by default.
That way if somebody decides to not use them then he/she should make it explicit by passing the use_length=False and use_hashes=False when calling the functions.

@joshuagl joshuagl added this to the Specification compliance – 1.0.0 milestone Jul 7, 2020
@MVrachev
Copy link
Collaborator

@joshuagl can you close this one? It's fixed by the above pr.

@joshuagl
Copy link
Member

Fixed in #1031

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