-
Notifications
You must be signed in to change notification settings - Fork 271
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
Metadata API: enforce role name uniqueness in delegations #1426
Comments
Potentially we could use As trishank mentioned on slack: from python 3.7 onwards Dict itself guarantees insert order so is deterministic -- for our uses OrderedDict still makes sense (and also informs the reader that the order matters) |
I would suggest discussing and solving this issue in the spec repo first so that we make sure we are on the same page with the spec. Otherwise, a good catch, and I agree with the sentiment that from my perspective I see only problems in allowing duplicate role names in delegations. |
The same is implied by the spec itself it just needs to be written explicitly I guess:
|
I want to work on this and will assign myself. |
The spec does not say anything about role name uniqueness in a delegations object but I believe we cannot safely allow multiple roles with same role name in the roles array of a delegations object. If we did then the roles could have different keyids, and then we would end up in a situation where a metadata may be both a valid delegation and an invalid delegation at the same time, depending on how the role gets chosen and that does not seem like the intention of the design.
I don't think there are real uses cases for non-unique role names in delegations either -- and I assume that this situation is just an unintentional side-effect of making roles an ordered list -- so the spec should possibly clarify that uniqueness is required (although I guess theoretically some complex ordering issue could be solved by multiple roles per role name).
Regardless, metadata API should IMO enforce role name uniqueness on Delegations.roles unless a good case is made against that.
The text was updated successfully, but these errors were encountered: