-
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
[WIP] Use separate keydb for delegated targets #1095
Conversation
This is awesome, thanks, Marina! I'm a bit ambivalent about continuing to use the global key dictionary, even if isolated by repositories. Ideally, this should be done recursively. I understand we need to make progress, but I'm also hesitant about adding code we will eventually need to rewrite anyway. It's a difficult problem. Thoughts @lukpueh @joshuagl @JustinCappos ? |
This means that all roles delegated to by root will look for keys from the root metadata, roles delegated to by targets will look for keys in targets metadata, and so on. This commit adds this functionality to the keydb and ensures that these separate keydbs are created and used for storing keys. It requires a future change to the roledb to store the delegating role and further testing. Signed-off-by: marinamoore <mmoore32@calpoly.edu>
This field can be used by delegated targets to determine which role delegated to them, and thus which keys should be used to verify the role. Signed-off-by: marinamoore <mmoore32@calpoly.edu>
Signed-off-by: marinamoore <mmoore32@calpoly.edu>
The repository keydb will no longer store keys for delegated roles. Instead look for these keys in delegated keydbs. Signed-off-by: marinamoore <mmoore32@calpoly.edu>
Signed-off-by: marinamoore <mmoore32@calpoly.edu>
Signed-off-by: marinamoore <mmoore32@calpoly.edu>
Signed-off-by: marinamoore <mmoore32@calpoly.edu>
…ydbs for delegations and add parent_role to roledb entries for delegations Signed-off-by: marinamoore <mnm678@gmail.com>
Signed-off-by: marinamoore <mnm678@gmail.com>
@mnm678 would you please kindly mark this as a draft PR until ready? Thanks! |
In a recent TAP meeting we agreed that it might be better to not rework keydb, but instead hold off the implementation of TAP 12 until we have better key handling infrastructure, as e.g. discussed in #1060 (comment). Should we close here, @mnm678? |
Yes, I'll close this and we can revisit the TAP 12 implementation in the future. |
Fixes issue: part 3 of #1084
To implement TAP 12, this pr adds separate keydbs for each delegating instance. This means that the roles delegated to by root will use one keydb, the roles delegated to by targets will use a different one, and so on.
To do so, this pr introduces keydb.create_keydb_from_targets_metadata to make a new keydb for all roles delegated to by a targets metadata file and adds a
parent_role
field to the roledb to keep track of what keydb should be used when verifying a role.