IndexKeys is run on pre-canonicalized entries

[asraa]

Description

Version

The flow of creating a log entry is curious to me:

rekor/pkg/api/entries.go

Line 173 in 4b93499

func createLogEntry(params entries.CreateLogEntryParams) (models.LogEntry, middleware.Responder) {

1. A new entry is created based on the parameter proposed entry.
2. A leaf node is created by canonicalizing the entry
3. The original entry calls index keys.

In many entry types, logic is performed in Canonicalize to set up the entry, and it's not clear that IndexKeys does not have access to the canonicalized entry fields. This is also a problem if Canonicalize does some operation that may modify IndexKeys.

I realized this was the root cause to the bug that @priyawadhwa fixed from #800 where assumed that intoto entries populated the Content Hash (but only canonicalized ones did).

Shouldn't IndexKeys operate on the canonicalized entry?

[asraa]

From @haydentherapper 👍

"Maybe we need to figure out how to do canonicalization very early on in the lifecycle of a request

so nothing ever operates on a non-canonical entry"

[dlorenc]

I'm not sure this is doable since we strip a lot of information during canonicalization, on purpose. It means the index entries aren't always verifiable or repairable, though.