You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description of issue or feature request:
By resolving issue #1139 we are going to add classes for all complex fields inside the top-level metadata classes e.g. meta/ targets (in Timestamp, Snapshot, Targets), delegations (in Targets), keys/roles (in not yet existent Delegation).
The problem is, that many of those complex fields are represented by a dictionary and we are adding classes for the values of
the dictionary in order to easily validate them later, but we should make sure to validate the dictionary keys as well.
Current behavior:
We are not validating dictionary keys yet.
Expected behavior:
We should make sure to validate:
It's validated that keyid is a string inside the Key class during initialization.
During serialization, it's not validated. Maybe there is no sense to add that as Key is an internal helper class and we don't expect the user to modify the Key instances.
Maybe we can validate that the given keyid actually points to the keyval given during the initialization of a Key instance?
It's problematic to validate that keyid points to exactly one keyval.
In timestamp, we have generally fixed that problem by removing meta and replacing it with snapshot_meta.
For Snapshot, I think we should at least check that METAPATH is a non-empty string.
I think we should at least validate that it's a non-empty string. as defined by the spec.
Maybe we do want to validate that TARGETPATH is not one of the top-level metadata files or roles? That sounds like a reasonable decision to prevent accidental mistakes.
@jku what's your opinion? I ask you as you reviewed other of my prs about validation.
With keyids I think there's very little we can or should do.
root rolenames are now validated in 1516. The additional things we maybe could still do are
mark roles as a Mapping (to indicate that users should not add or remove values from the dictionary during the lifetime of the Root object).
accept roles=None in the constructor (and create the default set in that case). This is not strictly validation but lowers the need for validation since then no-one ever needs to manually create the roles dict.
I think we should at least check that METAPATH is a non-empty string.
I think we should at least validate that it [TARGETPATH]'s a non-empty string
I think these make sense, yes
Maybe we do want to validate that TARGETPATH is not one of the top-level metadata files or roles?
that does not make sense for TARGETPATH but if you meant checking that METAPATH is not in ["root.json", "snapshot.json", "targets.json", "timestamp.json"]... that might make sense as a sanity check.
Uh oh!
There was an error while loading. Please reload this page.
Description of issue or feature request:
By resolving issue #1139 we are going to add classes for all complex fields inside the top-level metadata classes e.g.
meta
/targets
(in Timestamp, Snapshot, Targets),delegations
(in Targets),keys
/roles
(in not yet existent Delegation).The problem is, that many of those complex fields are represented by a dictionary and we are adding classes for the values of
the dictionary in order to easily validate them later, but we should make sure to validate the dictionary keys as well.
Current behavior:
We are not validating dictionary keys yet.
Expected behavior:
We should make sure to validate:
The text was updated successfully, but these errors were encountered: