theupdateframework / theupdateframework/specification

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

Open
#214 4 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
405
Forks
59
Avg merge
3d 4h
Merged PRs (30d)
1

Description

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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with section 6.3.1 of the specification and the related delegation-graph discussion in issue #177. Determine whether the specification should define thresholds per incoming delegation edge or require delegation trees; done means the delegated-targets wording unambiguously covers these cases.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.