Skip to content

fail reasonably on unsupported kindversions #1394

Open
@jku

Description

@jku

Currently if we encounter unexpected kindversions in the rekor log entry we fail when we parse the canonical body -- this looks ugly and hard to understand (see #1384 ).

The rekor v2 work both makes this more important to fix but maybe also easier to fix: After #1370 the situation is:

  • we always have a kindversion available in the LogEntry (private variable but still)
  • we can validate that we have something we will understand before we try to parse canonical body
  • this can happen in LogEntry._from_dict_rekor() (this would be in line with keeping kindversion an implementation detail) or it could happen in Bundle._verify() (this would be in line with us only parsing canonical body when we need it -- so a LogEntry with unrecognised kindversion would be fine but a Bundle requires a useful kindversion)
  • note that when we do this validation we strictly speaking do not know which rekor version generated the entry -- I dont think this an issue, just pointing it out

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions