search

theupdateframework / specification

The Update Framework specification
https://theupdateframework.github.io/specification/
Other
368 stars 54 forks source link

Correct and clarify "6.3.1 Updating targets metadata" for delegated targets roles #214

Open ethan-lowman-dd opened 2 years ago

ethan-lowman-dd commented 2 years ago

Step three of 6.3.1 states:

Sign the updated targets metadata with at least a THRESHOLD of keys for the associated targets role (either the top-level targets role, or a delegated targets role).

For delegated targets roles, keys are associated with delegations (edges), not roles (nodes) in the delegation graph. The spec glosses over a lot of detail here. I think the intended meaning is that for each incoming delegation to a role, the metadata is signed for a threshold of the keys for that specific delegation edge. There is not necessarily just one threshold or one set of keys.

I see two choices: we could fix the spec for all these edge cases for strange delegation graphs (e.g. https://github.com/theupdateframework/specification/issues/177), or adjust the spec to explicitly state that delegation graphs must be trees (i.e. each targets role must have only one incoming delegation). I haven't heard of anyone using non-tree delegation graphs in practice, and supporting these use cases makes code more complex, and therefore probably less secure.

lukpueh commented 2 years ago

Also related:

hosseinsia commented 2 years ago

+1000 Thanks Ethan for analysis. I think making it a tree is the right way to do this. Otherwise identify and key management would be a mess, and role-key relation for delegation diverges from what is for top-level. Adding tree constraint to the delegations makes the life of developers and the users way easier.

ethan-lowman-dd commented 2 years ago

To clarify: the reason restricting the delegation graphs to trees helps with the edge vs. node ambiguity is that with a tree delegation structure, associating keys with edges (delegations) is equivalent to associating keys with nodes (roles). This is because in a tree, there is exactly one incoming edge to each node, except for the root (top level targets).

JustinCappos commented 2 years ago

It does make things more difficult in situations where a repository is shared by different users that want to delegate to each other. I'm not sure if PyPI, TAF, or others want this model, but we should consider this before making the change.

On Tue, Apr 5, 2022 at 2:22 AM Ethan Lowman @.***> wrote:

To clarify: the reason restricting the delegation graphs to trees helps with the edge vs. node ambiguity is that with a tree delegation structure, associating keys with edges (delegations) is equivalent to associating keys with nodes (roles). This is because in a tree, there is exactly one incoming edge to each node, except for the root (top level targets).

— Reply to this email directly, view it on GitHub https://github.com/theupdateframework/specification/issues/214#issuecomment-1087872216, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD5QUUTDLPWOUQ5E4M3VDMXPTANCNFSM5R4JYR3A . You are receiving this because you are subscribed to this thread.Message ID: @.***>