dlorenc

> I remember this concern being brought up, but I don't really share it, because things generally just work if you use manifests in this way. +1, I think everybody...

> @dlorenc I would certainly appreciate including @jonjohnsonjr's example of how this would work in the spec, with the clarification on "Image Manifest" applications. Thanks for the feedback! We'll get...

> This is largely a dupe of the `oci.artifact.manifest` proposal. The main difference here is the `references` property is placed on a descriptor, as opposed to being in the manifest...

FYI: I updated the tracking issue here with some details on testing/validation. I've been unable to break any clients with this so far, but I appreciate any help in trying!

The cosign behavior is documented here as a "spec", with the intention of being interoperable! https://github.com/sigstore/cosign/blob/main/specs/SBOM_SPEC.md Either approach sounds great to me.

> https://github.com/github/memex/issues/3253#issuecomment-830091875 > > > This appears to be a link to an internal repository - FYI

I don't think it's really possible to meet the "Service generated" requirement on GitHub actions today. The main goal is that the provenance would be protected against the compromise of...

Nice, I like it.

I think I was worried about a specific issue with the GitHub actions cache, where someone had pointed out a few cross-build cache-poisoning attacks. I'd have to dig it up...

I think the language around all of the signing stuff needs to be improved a bit. Key management is only one part of the puzzle, without rotation/revocation you're really not...