asraa

> pkg/tuf should provide anything TUF-related (client side) to the rest of the sigstore projects. Correct! > As a side note here, I se e some parts of TUF-related code...

Chiming in to describe some updates after we've had some conversations. I think some of this echos @znewman01 discussion earlier. We MUST have the certificate to identify (with immutable references)...

> @asraa : To what extend did https://github.com/sigstore/cosign/pull/2461 address this? I think it's totally done. The one thing required is that the interface provided here is a lot cleaner than...

I have some example usage of a cosign verification for keyless signed blobs, not containers, but there is some overlap in how to verify the TLOG entries https://github.com/slsa-framework/slsa-verifier/blob/aee753f58fa9a4de2be6290e3eefae2d6e998a9d/pkg/provenance.go#L311 I'd be...

Could you please merge or rebase? I'll take a re-review! I think from what I read - sharding is currently changing, but the log-index is indeed unique enough to determine...

What if it were `verify-artifact --vsa`?

Ah true - yes, I only say this because I worry that for each command we'll have a (artifact/image) pathway like cosign. Hmmm Yeah, VSAs definitely seem like a different...

> My understanding was that it attests to when and by whom the package was published, but I'm not sure what else it might guarantee. Right, I think the implicit...

Or maybe there's a versioning in their buildType or something else to identify stable format?

I'm drafting the verification changes here: https://github.com/slsa-framework/slsa-verifier/compare/main...asraa:slsa-verifier:delegator-verification?expand=1, but I require some fixes (https://github.com/slsa-framework/slsa-github-generator/pull/1619) to actually test this. Then I will add tests. We have a slight chicken and egg problem...