fix: rekor get tlog entry with uuid

[asraa]

Signed-off-by: Asra Ali asraa@google.com

Sign blob w/ search otherwise doesn't work, because the UUID in the response of Rekor now includes a prefix shard UUID.

cc @priyawadhwa

Summary

Release Note

Documentation

Fixes #1406

[priyawadhwa]

nice!!

[dlorenc]

Codegen or a rebase issue?

[priyawadhwa]

I think an issue with compiling cosign, we might need to update to 1.18:

Error: ../../../go/pkg/mod/sigs.k8s.io/release-utils@v0.7.1/version/version.go:124:25: bi.Settings undefined (type *debug.BuildInfo has no field or method Settings)
note: module requires Go 1.18

[asraa]

I think an issue with compiling cosign, we might need to update to 1.18:

yeah, i'm seeing some problems when i run codegen locally as well. is this because rekor is at 1.18?

[priyawadhwa]

I think that sigs.k8s.io/release-util dependency requires 1.18. looks like rekor recently pinned to a specific version of it and updated the go version at the same time -- sigstore/rekor#904

[asraa]

ah nice find! i'll open a PR to bump to 1.18

edit: pending #2059

[asraa]

Confirmed this fixes goreleaser:

$ COSIGN_EXPERIMENTAL=1 ./cosign verify-blob   --signature https://github.com/goreleaser/goreleaser/releases/download/v1.10.3/checksums.txt.sig   https://github.com/goreleaser/goreleaser/releases/download/v1.10.3/checksums.txt
tlog entry verified with uuid: 6ad8e71d61e4757a7010ba3d31fca287db1e1e3ecdc09ebaeab317b7974f2581 index: 3045145
Verified OK

[asraa]

@priyawadhwa @dlorenc @hectorj2f sorry this got lost after the golang bump! but this will fix the recent goreleaser issue so I am reviving it.

[asraa]

Once again I have some dep problems... :/

[asraa]

@imjasonh I think I still require go 1.18 #2093

[dlorenc]

You should be able to rebase now!

[asraa]

Updated, thank you!

Note the comment in the dep check: If needed, I'll see if I can split up the sharding package's sharding computation from the stuff that requires Trillian clients.

[dlorenc]

Actually we need to hold on the trillian dep check I think, cc @vaikas and @mattmoor

[asraa]

Actually we need to hold on the trillian dep check I think, cc @vaikas and @mattmoor

Yeah, if this can't be WIP for a little time, I can copy/paste the sharding code with a TODO to remove the copy-paste. LMK

[vaikas]

I'd personally prefer to not pull that in as it has caused (well, not Trillian alone, but things with glog and other huge deps. My preference would be (I can't believe I'm saying this ;) ) cut&paste.

When you say it would be wip for little time, what's the actual fix that we would have to do?

But from this PR I don't quite get why we need to comment out the trillian bit, this doesn't seem to bring in new deps added, so I don't understand why we need to remove it.
My second question is just curiousity about leaking the the implementation details (but we don't have to discuss it here) about the trillian that sits behind rekor.

[vaikas]

Also, I know folks are sensitive to deps and sizes (I know when I inadvertently pulled in something that had a k8s dep :) )

[imjasonh]

The sharding.GetUUIDFromIDString method contains no trillian deps.

In fact, only needs the Trillian LogClient, and only that to have the method GetLatestSignedLogRoot, which unfortunately takes a trillian struct, otherwise we could replace trillian.TrillianLogClient with interface { GetLatestSignedLogRoot(...) } and remove this dep on trillian.

Another option would be to define a new interface TrillianLogClient with Get(treeID) and a real implementation somewhere in rekor/cosign that depends on trillian, only used by cmd/cosign and the Rekor server. This would remove dependencies from sharding->trillian, and would let us use GetUUIDFromIDString more easily in cosign and its deps. edit: This is a bit complicated because the LogRootV1 type is also responsible for unmarshaling the response bytes: https://github.com/sigstore/rekor/blob/83a4094253c9267d664dfddcf44ad5929a626bee/pkg/sharding/ranges.go#L99

Or, as @vaikas says, copy and paste sharding.GetUUIDFromIDString into cosign.

[asraa]

Or, as @vaikas says, copy and paste sharding.GetUUIDFromIDString into cosign.

Yeah exactly. I could either do this, since it's not complicated logic, but my main idea was to separate these sharding utils from the sharding code that manipulates and requires the trillian log client.

I'll resolve it internally. Before GA we will expose verification libraries with few deps in rekor anyway. And that will supersede all this code.

[asraa]

All set, PTAL. Added tests for all the cases of whether Rekor will return EntryUUIDs or UUIDs to make sure matching occurs correctly.

[dlorenc]

Looks like lint failures, feel free to either fix or skip for the copy/pasta'd code.