cosign
cosign copied to clipboard
sigstore
Plan for Reference Types Work!
Description
The reference types work is off and running now in OCI, and we should start to think through how we'll adopt it here in cosign.
Assuming the work completes, gets adopted by registries, and meets all the use cases required by cosign, we still have a few choices to make!
- When do we add support, and how? Do we need to wait for all registries to support it, or can we do a transition with a fallback option?
- How would a fallback work? Could we always check the new location and fall back to the old one? Should we always check both?
- How about writes? Always push to the new location first, then fallback to the old one?
- Should we just make it a config option?
I think as soon as there's a workable draft spec merged in https://github.com/opencontainers/wg-reference-types, we should create a dev branch here in cosign to let people try it out, without us needing to answer the fallback questions right away. Maybe a "cosign-oci-ref" build or something that only works with the new APIs.
We could also publish and run a ttl.sh-like ephemeral registry that supports the new API as it gets developed, to let people try it out against a real endpoint without requiring them to run something locally.
We should track the reference type work in GGCR's pkg/registry to test against. If we can flag this on/off then we can also test fallback.
Perhaps this is something to cross-post in GGCR repo, but yesterday the extensions proposal was merged: https://github.com/opencontainers/distribution-spec/tree/main/extensions
Regarding fallback options, etc., this is how clients will be able to determine if experimental APIs defined in the working group are exposed by a given registry
Just want to bump this now that the working group for reference types has concluded:
https://github.com/opencontainers/wg-reference-types
There's some work ongoing in ggcr now: https://github.com/google/go-containerregistry/pull/1455
When that gets closer to landing I will try to see how cosign should use it, to make sure it's a good fit, and so sigstore-go gets a good go API for discovering attached things by type.
We'll probably also need cosign to maintain a compat mode for some time (forever?) so signatures etc that were attached using cosign's scheme remain discoverable. That code should only live in sigstore-go.
If folks have opinions or ideas about how they'd like this to look and feel please share!
https://github.com/sigstore/cosign/pull/2684 "only" handles signatures and SBOMs, which is great! Is the same thing eventually planned for attestations, too?
I still cannot decide if I should publish my SBOMs as sbom- or att-artifacts.
#2684 "only" handles signatures and SBOMs, which is great! Is the same thing eventually planned for attestations, too?
Yes! We just wanted to get something out so people could play with it, then fine-tune the support before we drop the "experimental" tag.
Now that the sbom-type attachments have been deprecated in https://github.com/sigstore/cosign/pull/3256, I am trying to convert to attestations.
Unfortunately https://github.com/sigstore/cosign/pull/2684 only added (experimental) support for signatures and sbom-attachments (which are now deprecated), but not for attestations. This is unfortunate, because the zot registry does not support docker-specific media types:
$ cosign attest --tlog-upload=false --predicate cdx.sbom.json --type cyclonedx --key cosign.key localhost:5000/some-project/my-image:sha256:856f88f0c75ab14cc6e4f31776d41de7fe02971d146cf5118b840a662dc5ff00
Enter password for private key:
Using payload from: cdx.sbom.json
Error: signing localhost:5000/some-project/my-image:1.0.0: PUT http://localhost:5000/v2/some-project/my-image/manifests/sha256-856f88f0c75ab14cc6e4f31776d41de7fe02971d146cf5118b840a662dc5ff00.att: MANIFEST_INVALID: manifest invalid; [map[mediaType:application/vnd.docker.distribution.manifest.v2+json]]
main.go:74: error during command execution: signing localhost:5000/some-project/my-image:1.0.0: PUT http://localhost:5000/v2/some-project/my-image/manifests/sha256-856f88f0c75ab14cc6e4f31776d41de7fe02971d146cf5118b840a662dc5ff00.att: MANIFEST_INVALID: manifest invalid; [map[mediaType:application/vnd.docker.distribution.manifest.v2+json]]
Signatures and sbom-attachments work fine with Zot (when using the experimental oci-1-1 mode), but not attestations.
Sorry to bump this, but is there a roadmap for this? There hasn't been any activity in this issue for a year now. Is there even any interest in supporting to store signatures and attestations as true OCI artifacts?
The deprecation of SBOM attachments makes it impossible for us to publish SBOMs as attestations to a registry that doesn't support proprietary docker image types.