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
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
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
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:
LogEntry._from_dict_rekor()
(this would be in line with keeping kindversion an implementation detail) or it could happen inBundle._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)The text was updated successfully, but these errors were encountered: