-
Notifications
You must be signed in to change notification settings - Fork 275
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 Attribute research: Threshold #1439
Comments
Would love to hear @jku opion. |
once we get to repository-side code, Role and DelegatedRole will be modified though: threshold and keyids do potentially change. Not much thought has been put into this yet (possibly we want more API than |
One alternative to this is to consider Role and DelegatedRole immutable objects: when repository code wants to change keys or threshold of a role, it should just add/remove/replace the complete role instead of modifying the keys/threshold in the role. This way it would be easier to ensure that e.g. the delegation keys includes the keys (and only the keys) that are actually used by current delegation roles. Regardless, i don't think this should affect what you do to threshold within the Role object: what you're planning seems fine. |
I think mentally I always considered |
This issue aims to document thoughts about the
Threshold
attribute from theroot
andtargets
roles and more precisely in our implementationRole
andDelegatedRole
classes.The goal is to understand how we use that attribute, what might go wrong with it and how we can validate it.
We want to answer/address the following 6 questions/points based on my comment here:
PS: The 7-th point is covered by documenting this issue.
The text was updated successfully, but these errors were encountered: