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

Functional bug: Pulling only first UUID for blob verification without certificate #1647

Closed
asraa opened this issue Mar 22, 2022 · 4 comments
Closed

Comments

@asraa
Copy link
Contributor

asraa commented Mar 22, 2022

uuids, err := cosign.FindTLogEntriesByPayload(ctx, rClient, blobBytes)
if err != nil {
return err
}
if len(uuids) == 0 {
return errors.New("could not find a tlog entry for provided blob")
}
tlogEntry, err := cosign.GetTlogEntry(ctx, rClient, uuids[0])
if err != nil {
return err
}
certs, err := extractCerts(tlogEntry)
if err != nil {
return err
}
co := &cosign.CheckOpts{
RootCerts: fulcio.GetRoots(),
CertEmail: certEmail,
CertOidcIssuer: certOidcIssuer,
}
cert = certs[0]

In case a cert or key ref isn't passed into verify-blob, we use the FIRST UUID uploaded in rekor for the certificate. IMO, I don't think this is correct behavior -- especially since this supports pinning an expected cert email. The first UUID may not be the expected certificate.

Anyway, I'm not sure that searching by payload without the certificate is great behavior -- at least clients should log that they're doing a best effort search for the signing certificate.

@haydentherapper

@dlorenc
Copy link
Member

dlorenc commented Mar 22, 2022

Is this the same issue #1447 ?

@haydentherapper
Copy link
Contributor

These seem the same.

@dlorenc
Copy link
Member

dlorenc commented Mar 22, 2022

+1 on pulling them all, and then also displaying a message explaining the guarantees of the search API. Basically - the results returned are guaranteed to be valid, but we can make no guarantees that every valid entry is returned.

@asraa
Copy link
Contributor Author

asraa commented Mar 22, 2022

Basically - the results returned are guaranteed to be valid, but we can make no guarantees that every valid entry is returned.

Great, right!

I'll close this issue in favor of that one, and open up a fix PR for more discussion. I think it should display a message as soon as it reached the experimental case to strongly suggest that passing in a certificate in the CLI.

@asraa asraa closed this as completed Mar 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants