-
Notifications
You must be signed in to change notification settings - Fork 54
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
Clarify client traversal of role delegation graph #177
Comments
I think in the more general case (especially multi-role delegations), you want to avoid delegations you have seen before. So, in the typical single-role delegation case, that means you want to avoid roles you have seen before. Even in the multi-role delegation case, you want to avoid the exact combination of roles (i.e., AND of thresholds of public keys) you have seen before, and even that can broken down into single roles (i.e., if you have seen a rolename before, even if it is being delegated a different threshold of different public keys now, you know can you avoid it because you clearly haven't found what you were looking for). Did I miss anything @mnm678? |
This is a good catch, and certainly something that we should clarify. I agree with @trishankatdatadog. We want to avoid visiting the same node multiple times so that roles don't accidentally get added multiple times to a threshold, etc. While TUF does not actually require delegations to be a tree, in most cases they will be. Further, delegators are aware of TUF semantics, and can, for example, create a new role with some similar keys if for some reason this role needs to exist at multiple levels of the graph. |
The legacy client in the reference implementation keeps a |
On the new ngclient _preorder_depth_first_walk keeps a set of edges: (node, parent_node) any skips visited edges. |
I should clarify: my statement is true for some role X that you have visited alone (i.e., a single-role delegation) before seeing it later as part of a multi-role delegation. OTOH, it is not true if you visited X as part of some multi-role delegation earlier, before encountering it again later in some new multi-role delegation... |
Thank you for the detailed issue @raphaelgavache! Apologies all for the noise of the drive-by comment earlier, I wanted to some implementation examples and submitted before the comment was complete.
I believe a new set of contributors drew different conclusions from the specification, further indicating the need to clarify this part of the detailed client workflow. I'd certainly defer to @trishankatdatadog and @mnm678 here, but I my current understanding is in agreement with the ngclient authors conclusion (and yours, I believe, @raphaelgavache) that we should skip visited delegations/edges not visited roles/nodes. |
I can see the different potential approaches but I'm considering reverting this decision in ngclient:
So I think I'll propose changing that (thanks raphael for pointing that out). If anyone has opinions, please -> theupdateframework/python-tuf#1528 |
This change edits the ngclient `Updater` to traverse the delegation tree on nodes, instead of edges in order to skip already visited nodes. For more detailed clarification, please review theupdateframework/specification#177 Fixes theupdateframework#1528 Signed-off-by: Ivana Atanasova <iyovcheva@iyovcheva-a02.vmware.com>
This change edits the ngclient `Updater` to traverse the delegation tree on nodes, instead of edges in order to skip already visited nodes. For more detailed clarification, please review theupdateframework/specification#177 Fixes theupdateframework#1528 Signed-off-by: Ivana Atanasova <iyovcheva@iyovcheva-a02.vmware.com>
Spec v1.0.19 Section 5.6.7 describes how the client should traverse the delegation graph to update the targets role. The wording on cycle avoidance could use some clarification.
The spec says:
A "role" in this context could either refer to 1) a delegated role (a node in the delegation graph) or 2) a
role
entry in theroles
array of theDELEGATIONS
object, which represents not a role, but a delegation from one role to another (a directed edge in the delegation graph).As a result, there are two ways the traversal could be interpreted:
Below are two concrete examples.
Example A:
Example B:
(assume
B
's outgoing edges/delegations are ordered as[A, D]
cc: @trishankatdatadog
The text was updated successfully, but these errors were encountered: