Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor Metadata._get_role_and_keys() #2272

Closed
jku opened this issue Jan 13, 2023 · 4 comments
Closed

refactor Metadata._get_role_and_keys() #2272

jku opened this issue Jan 13, 2023 · 4 comments

Comments

@jku
Copy link
Member

jku commented Jan 13, 2023

EDIT: This relates to code in #2165 -- should likely be fixed in that PR

Looking at Metadata._get_role_and_keys() after a while... I did not do a good job of it.

Potential improvement:

  • it should return only the keys for the delegated role (instead of all delegated keys and the specific Role). I was probably avoiding unnecessary allocations here but this makes the code harder to read
  • does not have to return the whole role but does have to return threshold instead
  • the method should be public as it's useful in applications as well
  • these changes mean some changes in verify_delegate()

Something like this

    def get_keys_and_threshold(self, delegated_role: str) -> Tuple[List[Key], int]:
@lukpueh
Copy link
Member

lukpueh commented Jan 13, 2023

FYI, I also changed this method in #2246 to get keys and threshold from an explicitly passed Signed object instead of self.signed.

I needed this for a common abstraction of Metadata and Envelope (dsse) classes, which accesses self.signed via getter method, that, in the case of Envelope, takes an optional (deserialization) argument.

@jku
Copy link
Member Author

jku commented Jan 15, 2023

That leads to the conclusion that metadata is the wrong location to begin with? I think I might agree with that: Targets and Root objects could both implement a method with the same signature (in effect implementing a hypothetical Delegator Protocol)

@jku
Copy link
Member Author

jku commented Jan 17, 2023

I just tried this and it looks a lot simpler: will fix this in the no-key branch/PR

@jku
Copy link
Member Author

jku commented Jan 17, 2023

closing: this is reviewed as part of #2165

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants