feat: refactor: use sigstore-go for fetching TrustedRoot

[ramonpetgrave64]

Uses the sigstore-go library for fetching the TrustedRoot, which contains the Sigstore infrastructure certificates needed to validate the leaf ephemeral certificates used to sign artifacts.

Refactors:

• replace TrustedRootSingleton() with getDefaultCosignCheckOpts(), since only VerifyImage() will now need that data.
• replace cosign.ValidateAndUnpackCert withsigstoreVerify.VerifyLeafCertificate()
• use sync.Once for sigstore and rekor clients, and the TrustedRoot

Testing

• existing tests continue to pass
  • negative tests against rekor TLogs
• manual invocations of verify-artifact.

[ramonpetgrave64]

@haydentherapper @laurentsimon

[ramonpetgrave64]

@loosebazooka

[haydentherapper]

Nice work on this! Just one remark about long-running processes.

[haydentherapper]

Should we handle slsa-verifier used in any long-running (> 1 day) processes? If so, then we should look at using LiveTrustedRoot to refresh the root periodically.

[ramonpetgrave64]

It makes sense to do that, but I feel we need to change the NewLiveTrustedRoot to accept an existing TUFClient, rather than make a new one. wdyt?

• https://github.com/sigstore/sigstore-go/blob/2b6fc6df45dc26c329f4da6c8157340e0f435a0d/pkg/root/trusted_root.go#L310

from

func NewLiveTrustedRoot(opts *tuf.Options) (*LiveTrustedRoot, error)

to

func NewLiveTrustedRoot(c *tuf.Client) (*LiveTrustedRoot, error)

[ramonpetgrave64]

IIUC, we don't need to explicitly cache TrustedRoot, because the TUFClient will already cache it with GetTarget(). Is that right?

[ramonpetgrave64]

following up in sigstore/sigstore-go#249

[haydentherapper]

GetTarget caches the target file to prevent redownloading it. Separately, the TUF client will still check if the local TUF repository metadata needs to be updated. If caching is configured (https://github.com/sigstore/sigstore-go/blob/main/pkg/tuf/options.go#L47), then the client will only fetch new targets once the local timestamp has expired or the cache validity window has passed.

For an API to accept a TUF client, one issue is that the underlying Updater can only have Refresh called once (https://github.com/theupdateframework/go-tuf/blob/f95222bdd22d2ac4e5b8ed6fe912b645e213c3b5/metadata/updater/updater.go#L105) (I'm not sure why that is the decision, we can ask Fredrik on the issue). If the live updater accepts an existing TUF client, it will need to reinitialize the Updater, which will need the options.

[haydentherapper]

Since the current implementation just supports verifying from the public instance, WDYT about proceeding with using NewLiveTrustedRoot as-is, since a custom TUF client shouldn't be necessary?

[ramonpetgrave64]

Added.

It seems counter to our other plans for allowing slsa-verifier users to pass their own TUF client. But slsa-verifier needs to do live lookups against the public Sigstore infra, yes, I would be okay with not using the user-provided TUF client.

• feat: VerifyNpmPackage API with supplied tuf client #768

[haydentherapper]

Thanks, looks great! I’ll follow up about the API and TUF clients on the other PR.