sigstore
Brainstorming: Cosign v3 and beyond
Description
We've begun brainstorming what changes we'd like to make as part of the next major release of Cosign. We've been working on a number of related issues over the last year, tagged "pre-theseus", to modernize Cosign and bring it into conformance with newer Sigstore SDKs and clients that implement the Sigstore client specification. The next major release of Cosign, Cosign v3, will continue our modernization efforts.
We've copied in the notes from our most recent brainstorm, outlining the changes we'd like to make, to be formalized later on. Please chime in with thoughts or concerns! If you're interested in discussing Cosign v3, come join our bi-weekly discussions on Thursdays at 1pm PST/4pm EST, on the Sigstore community calendar.
- Default to using the bundle protobuf specification
- Drop support for blob / attestations using old format
- Review tooling to migrate old bundles to new format - issue. There is currently
cosign bundle create. - Allow containers to use old format with special flag
- Container "bundle" doesn't have an upgrade CLI tool today
- This isn't just a format change, it also involves the referrer spec and what we're signing over
- https://github.com/sigstore/cosign/issues/3927 for containers with signatures as OCI artifacts
- Container "bundle" doesn't have an upgrade CLI tool today
- Default to using trusted root verification material
- Drop support for providing verification material any other way
- Review existing subcommands and eliminate most of them
- Container manipulation commands should move to crane
- Things outside of blobs / attestations / container images should be removed
- Dropping support for online Rekor verification
- Verification path -> just sigstore-go?
- Yes please! cosign v2.4.0 has been using sigstore-go for trusted root verifications without any users reporting issues
- Verification path -> just sigstore-go?
- Signing changes
- Use sigstore-go for signing! This isn't top priority, but it adds features like support for signing config.
- For container signing we'll have to do some surgery around how cosign handles signing today
- Add
cosign signing-config create
- cosign as an API?
- Eh, maybe in v4; use sigstore-go for now
- Maybe it's not much work and we could squeeze it into v3?
- cosign has nice container features over sigstore-go that people might want to use as a library
- We could refactor cosign so that the container parts are a library that other Go projects can easily use
- Model signing is very similar - it mostly gets the digest from the model, and uses existing tools to do the actual signing
- Rethinking how cosign behaves with attestations
- Cosign support for SLSA Source Track · Issue #4210
- Remove the SBOM and SLSA provenance specific implementation
- There isn't an easy way to create in-toto attestations in Go today
- Tiny tools!
- See things like https://gitlab.com/components/slsa/-/blob/main/templates/provenance-verifier.yml#L106-146
- What are the cosign v3 user journeys?
- Why should people adopt it?
- How are we making people's lives easier?
- Drop support for TUF v1 client and disparate key material
- Drop support for verifying detached SCTs
We should confirm that local/offline verification of container images still works, and update save to pull referring artifacts.
We'd like to see SHA-384/512 support, ref: https://github.com/sigstore/cosign/pull/3917 as seemed to require some coordinated effort, it being a v3 item sounds reasonable.
--new-bundle-format in V3 breaks current bootc images that use cosign verification. It also breaks cosign v2 verification without changing args.
To avoid stranded users, we will need to provide/have available --new-bundle-format=false for the next 3 or so years and support both in the interim.
* How are we making people's lives easier?
Congrats on v3!
Speaking as Debian maintainer of Sigstore-related packages in general and cosign in particular, and someone who worry about the supply-chain safety of critical pieces of infrastructure, what would really help is if you would think about which (recursive) dependencies Sigstore/cosign requires. In our build logs you can see what kind of dependencies are dragged in to build cosign:
https://buildd.debian.org/status/fetch.php?pkg=cosign&arch=amd64&ver=2.5.0-2%2Bb4&stamp=1750612633&raw=0
That's for v2.5.0 (we are behind on packaging the latest versions due to new dependencies) but it is already 534 packages that are needed to build cosign. That's 534 packages that have to be audited for security vulnerabillities and xz-style malicious code. I don't have any particular examples, but I'm fairly sure that at least some of those packages are not declared stable by the maintainer nor have seen proper security audits. I'm also guessing that some dependencies have been officially been marked as deprecated by the maintainer.
Sorry if I sound negative, I'm just trying to chime on what I believe is an important aspect that may not be catching everyone's attention normally. Keep up the good (productive) work!
Thanks, Simon
--new-bundle-formatin V3 breaks current bootc images that use cosign verification. It also breaks cosign v2 verification without changing args.To avoid stranded users, we will need to provide/have available
--new-bundle-format=falsefor the next 3 or so years and support both in the interim.
For older signatures, we'd recommend either using cosign bundle create to generate a bundle (if you run into issues, let us know, we are planning to flesh out this command more!) or recommending users verify with Cosign v3 for now. Note that 3 years of support is beyond our versioning policy, though we'll backport security or critical bug fixes as needed.
* How are we making people's lives easier?Congrats on v3!
Speaking as Debian maintainer of Sigstore-related packages in general and cosign in particular, and someone who worry about the supply-chain safety of critical pieces of infrastructure, what would really help is if you would think about which (recursive) dependencies Sigstore/cosign requires. In our build logs you can see what kind of dependencies are dragged in to build cosign:
https://buildd.debian.org/status/fetch.php?pkg=cosign&arch=amd64&ver=2.5.0-2%2Bb4&stamp=1750612633&raw=0
That's for v2.5.0 (we are behind on packaging the latest versions due to new dependencies) but it is already 534 packages that are needed to build cosign. That's 534 packages that have to be audited for security vulnerabillities and xz-style malicious code. I don't have any particular examples, but I'm fairly sure that at least some of those packages are not declared stable by the maintainer nor have seen proper security audits. I'm also guessing that some dependencies have been officially been marked as deprecated by the maintainer.
Sorry if I sound negative, I'm just trying to chime on what I believe is an important aspect that may not be catching everyone's attention normally. Keep up the good (productive) work!
Thanks, Simon
Hey Simon, this is a great point. To confirm, do you need support for signing or just verification?
We filed https://github.com/sigstore/cosign/issues/3961 a bit ago to build a lightweight verification-only binary (with the larger KMS, cloud and container dependencies removed), and would like to continue to prune the dependency graph for the underlying sigstore-go library.
Pruning the signing dependencies is a bit harder, but we could explore doing the same, turning https://github.com/sigstore/sigstore-go/blob/main/examples/sigstore-go-signing/main.go into a well-supported binary and only supporting what the standard library offers (e.g. no KMS).
--new-bundle-formatin V3 breaks current bootc images that use cosign verification. It also breaks cosign v2 verification without changing args. To avoid stranded users, we will need to provide/have available--new-bundle-format=falsefor the next 3 or so years and support both in the interim.For older signatures, we'd recommend either using
cosign bundle createto generate a bundle (if you run into issues, let us know, we are planning to flesh out this command more!) or recommending users verify with Cosign v3 for now. Note that 3 years of support is beyond our versioning policy, though we'll backport security or critical bug fixes as needed.
Cosign verification is part of the update mechanism of bootc images. So when fedora updates to cosign 3, users that update will receive it, users that don't won't and will still have Cosign 2.6.0. To avoid having stranded users, we will need to push the legacy bundle for the next 2-3 years so that those users can still update.
As long as it keeps being supported by the latest version of cosign for that time, it's ok.
Just ran into this today with mise (https://github.com/jdx/mise/discussions/6655) trying to update cosign itself. It now fails with
mise ERROR Failed to install aqua:sigstore/[email protected]:
0: Cosign bundle verification error for aqua:sigstore/[email protected]: Verification failed: No bundle found in attestation
Is my understanding correct that the user needs to specify which bundle format they want to use on a case by case basis, depending on which format was used for the signing? If so, then that will make the transition period very rough. I imagine everyone is going to need to wrap cosign in a "try the new format, and if it fails, try the old format"
What are the cosign v3 user journeys?
- Why should people adopt it?
- How are we making people's lives easier?
Did this make it into the release somewhere? (I've got an implementation of the original signing format and I'm honestly really struggling to see the benefits of any of the "bundle" formats)
We touched on some of these points in https://blog.sigstore.dev/cosign-3-0-available/, but I'll highlight the main ones.
One of the goals with Cosign v3 was conformance with other Sigstore SDKs. The bundle format means that Cosign can verify content signed by any SDK, and similarly other clients can verify signatures produced by Cosign. The older signature format was not standardized across clients.
Another change was to use referring artifacts to store signatures/attestations rather than attach them as annotations. I think again this is a win for cross-ecosystem compatibility as we are leveraging an OCI spec for storage and discovery.