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

metadata API: avoid raising securesystemslib exceptions #1646

Closed
jku opened this issue Oct 27, 2021 · 2 comments · Fixed by #1734
Closed

metadata API: avoid raising securesystemslib exceptions #1646

jku opened this issue Oct 27, 2021 · 2 comments · Fixed by #1734
Assignees
Labels
1.0.0 blockers To be addressed before 1.0.0 release backlog Issues to address with priority for current development goals discussion Discussions related to the design, implementation and operation of the project
Milestone

Comments

@jku
Copy link
Member

jku commented Oct 27, 2021

I think Metadata API should not require its users to import securesystemlib exceptions to be able to call Metadata API methods, it just seems weird -- as a user of TUF I am not necessarily directly using securesystemslib at all, yet I need to handle exceptions from it

Current behavior:

sign(), from_file() and to_file() are documented to raise these exceptions

Expected behavior:

I should only need to import modules from tuf to be able to handle tuf exceptions. This could mean either

  • re-exporting the securesystemslib exceptions in tuf metadata or exceptions module or
  • handling the securesystemslib exceptions and raising something in python-tuf: this is what I think verify_delegate() does
@jku jku added the discussion Discussions related to the design, implementation and operation of the project label Oct 27, 2021
@MVrachev
Copy link
Collaborator

MVrachev commented Nov 9, 2021

I agree with the objective of the issue.
I think each of the cases should be solved separately as a securesystemslib exception can describe exactly what we want to tell the user in an eventual problem and other times the securesystemslib exception will be an implementational detail.

@sechkova sechkova added the backlog Issues to address with priority for current development goals label Nov 10, 2021
@sechkova sechkova added this to the Sprint 14 milestone Dec 8, 2021
@jku
Copy link
Member Author

jku commented Dec 21, 2021

After some discussion last week and looking at this again: I think at least sign() should operate like the verify functions: handle the sslib exceptions and raise just a single exception (UnsignedMetadataError seems appropriate). I've been trying to imagine a scenario where a repository would like to handle the individual errors... and I cannot think of any, they don't seem useful.

@MVrachev MVrachev added the 1.0.0 blockers To be addressed before 1.0.0 release label Jan 11, 2022
@jku jku modified the milestones: Sprint 14, Sprint 15 Jan 12, 2022
@jku jku modified the milestones: Sprint 15, sprint 16 Jan 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.0.0 blockers To be addressed before 1.0.0 release backlog Issues to address with priority for current development goals discussion Discussions related to the design, implementation and operation of the project
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants