Conversation
Roles were a bit too tightly coupled to the root roles, change this around a tiny bit so we can add delegations support Signed-off-by: Appu Goundan <appu@google.com>
| <T extends SignedTufMeta> Optional<MetaFetchResult<T>> getMeta(Role.Name name, Class<T> roleType) | ||
| throws IOException, FileExceedsMaxLengthException; | ||
| <T extends SignedTufMeta<? extends TufMeta>> Optional<MetaFetchResult<T>> getMeta( | ||
| String name, Class<T> roleType) throws IOException, FileExceedsMaxLengthException; |
There was a problem hiding this comment.
It's probably obvious, but I don't quite see why we're relaxing from an enum to a string here.
There was a problem hiding this comment.
Is it because deserializing an unknown enum value would fail while we might want to skipping unknown roles instead?
There was a problem hiding this comment.
Cause you can grab a meta of a delegated target which names are not predefined?
There was a problem hiding this comment.
oh I see. Should we rename the field to be more descriptive since it's just string? I don't remember anymore what it represents. roleName? targetName?
There was a problem hiding this comment.
Just wondering: does it mean we must never use enum when deserializing input?
Should we replace enum HashAlgorithm with string as well?
There was a problem hiding this comment.
I don't think we were ever using the enum at parsing time. It looked like we were using the enum as a naming constraint within the code.
The description for Roles is here: https://theupdateframework.io/metadata/
But functionally, it's an object in an entity that is used to sign metadata.
So root contains roles for root, snapshot, timestamp and targets (the RootRole in this PR)
Target can contain roles for delegations (more targets) and these delegations can contain more roles for more delegations (creating some sort of tree).
Roles were a bit too tightly coupled to the root roles, change this around a tiny bit so we can add delegations support