Metadata API: validate root role names #1630
Conversation
MVrachev
force-pushed
the
validate-role
branch
from
9cb7def to
aafa75a
Compare
|
The CI failures are fixed in #1631. |
MVrachev
force-pushed
the
validate-role
branch
from
aafa75a to
c43ef49
Compare
Pull Request Test Coverage Report for Build 1381179026
💛 - Coveralls |
| roles = {role_name: Role([], 1) for role_name in TOP_LEVEL_ROLE_NAMES} | ||
| root = Root(1, SPEC_VER, self.safe_expiry, {}, roles, True) | ||
|
|
||
| for role in TOP_LEVEL_ROLE_NAMES: |
There was a problem hiding this comment.
Note that sets are unordered. If the original order, i.e. ["root", "timestamp", "snapshot", "targets"], needs to be guaranteed, you can't use TOP_LEVEL_ROLE_NAMES here.
There was a problem hiding this comment.
Good note. I don't think the order matters here, am I right @jku?
Also, I decided to use a set, instead of a list for TOP_LEVEL_ROLE_NAMES because of this check:
if set(roles) != TOP_LEVEL_ROLE_NAMES: in tuf/api/metadata.py in Root.init() will result as false even if roles have the same content as TOP_LEVEL_ROLE_NAMES. The reason is that one is a list and the other is a set.
There was a problem hiding this comment.
I think using a set makes sense. If it turns out that there are many use cases that require the same particular order of the top-level role names, we can still add another global that is a list, or make this one an ordered set.
| @@ -728,6 +728,9 @@ def __init__( | |||
| super().__init__(version, spec_version, expires, unrecognized_fields) | |||
| self.consistent_snapshot = consistent_snapshot | |||
| self.keys = keys | |||
| if set(roles) != TOP_LEVEL_ROLE_NAMES: | |||
| raise ValueError("Role names must be the top-level metadata roles") | |||
|
|
|||
There was a problem hiding this comment.
It might be helpful to include the received, i.e. roles and expected, i.e. TOP_LEVEL_ROLE_NAMES value in the error message. I can't remember, do we have a general recommendation for error messages in that regard?
There was a problem hiding this comment.
I'd avoid any complexity. We're preparing for one of two options:
- deserialization: error message won't be useful
- construction of new Root: this is code that we hopefully write once in a repository component and that's it
complex error message would have very limited value in both cases
This constant can be used across tuf without defining it each time. Signed-off-by: Martin Vrachev <[email protected]>
Validate that root role names are 4 and that they are exactly "root", "snapshot", "targets" and "timestamp" as described in the spec: https://theupdateframework.github.io/specification/latest/#root-role Additionally, fix the valid_roots dataset, so each of the cases contains the top metadata role names inside the roles dictionary. Signed-off-by: Martin Vrachev <[email protected]>
Signed-off-by: Martin Vrachev <[email protected]>
MVrachev
force-pushed
the
validate-role
branch
from
c43ef49 to
4158272
Compare
| roles = {role_name: Role([], 1) for role_name in TOP_LEVEL_ROLE_NAMES} | ||
| root = Root(1, SPEC_VER, self.safe_expiry, {}, roles, True) | ||
|
|
||
| for role in TOP_LEVEL_ROLE_NAMES: |
There was a problem hiding this comment.
I think using a set makes sense. If it turns out that there are many use cases that require the same particular order of the top-level role names, we can still add another global that is a list, or make this one an ordered set.
Pull Request Test Coverage Report for Build 1380621788Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
Fixes #1516
Description of the changes being introduced by the pull request:
Validate that root role names are 4 and that they are exactly
"root", "snapshot", "targets" and "timestamp" as described in
the spec:
https://theupdateframework.github.io/specification/latest/#root-role
Additionally, fix the valid_roots dataset, so each of the cases contains
the top metadata role names inside the roles dictionary.
Signed-off-by: Martin Vrachev [email protected]
Please verify and check that the pull request fulfills the following
requirements: