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 <mvrachev@vmware.com>
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 <mvrachev@vmware.com>
Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
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.
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 mvrachev@vmware.com
Please verify and check that the pull request fulfills the following
requirements: