Support OCI layout signature storage

[bitoku]

Currently OCI layout destination doesn't support signature.

https://github.com/containers/image/blob/3152ce9a40792572a5536accef3aaf4ca90a44f0/oci/layout/oci_dest.go#L27-L37

However, cosign can save signatures in oci layout.

https://github.com/sigstore/cosign/blob/main/pkg/oci/layout/write.go
cri-o/cri-o#9135 (comment)

Is there any reason c/image doesn't support signatures for OCI layout destination?

[mtrmac]

Thanks for reaching out. The ability to store sigstore signatures in oci: is reasonable, it just hasn’t been implemented.

… but I never had a reason to investigate cosign/pkg/oci/layout. That layout is different from the on-registry one, which is not at all what I expected — notably it doesn’t work cleanly well for storing / updating multiple images in a single directory. And, in the meantime, the registry mechanism has changed to be based on registry subject referrers.

So we have ~3 possible candidates for the storage layout, and it’s not obvious that any of them should be preferred.

[bitoku]

Thank you @mtrmac for explaining.

I'm willing to contribute to this feature if nothing blocks it.
Would you mind explaining the possible ways you have in mind?

[mtrmac]

If this should happen, I think it would be a fairly straightforward extension of the relevant implementation of the ImageSource/ImageDestination interfaces. (Actually the way signatures are currently not implemented is perhaps less straightforward, with stubs.NoSignatures…).

My primary design concern is actually choosing a representation. We obviously don’t want all three. Longer-term, the referrer one might be closest to a standard, but it’s not yet a default in cosign, and it’s not yet implemented for the docker:// transport at all. So, doing something different for docker:// and oci: would, for now, look surprising.

I suppose one way to handle that would be to (finally?) add a referrer support to docker://, and then do referrers-only in oci:.

To this day, I have never seen anyone refer to the cosign OCI representation, and if I understand the linked issues, the use case you are considering does not actually care about cosign interoperability. And it does not scale. So, at a first glance, I’m inclined to rule that one out.

[bitoku]

@mtrmac
You've got a point. We don't need interoperability with cosign.

What do you think about supporting tab-based way?
https://github.com/sigstore/cosign/blob/main/specs/SIGNATURE_SPEC.md#tag-based-discovery

docker:// already supports this way so it's not surprising, and also follows the cosign specification although we don't necessarily follow it.