Skip to content

Conversation

@steiza
Copy link
Member

@steiza steiza commented Jul 31, 2025

Summary

This is a first step towards #4221, where we default --new-bundle-format to true instead of false.

We never did add protobuf support to cosign sign (see #3927 and #3139) - maybe we want to wait until that is done? Otherwise we could just have --new-bundle-format default to true when we add it to cosign sign.

Release Note

  • Modified attest, attest-blob, sign, sign-blob, dockerfile-verify, manifest-verify, verify, verify-attestation, verify-blob, verify-blob-attestation so that --new-bundle-format defaults to true instead of false.

Documentation

Ran make docgen as part of this PR.

@codecov
Copy link

codecov bot commented Jul 31, 2025

Codecov Report

❌ Patch coverage is 10.81081% with 33 lines in your changes missing coverage. Please review.
✅ Project coverage is 34.32%. Comparing base (2ef6022) to head (535b5c0).
⚠️ Report is 519 commits behind head on main.

Files with missing lines Patch % Lines
cmd/cosign/cli/verify/verify.go 0.00% 14 Missing ⚠️
cmd/cosign/cli/verify/verify_attestation.go 0.00% 14 Missing ⚠️
cmd/cosign/cli/options/attest.go 0.00% 1 Missing ⚠️
cmd/cosign/cli/options/attest_blob.go 0.00% 1 Missing ⚠️
cmd/cosign/cli/options/sign.go 0.00% 1 Missing ⚠️
cmd/cosign/cli/options/signblob.go 0.00% 1 Missing ⚠️
cmd/cosign/cli/options/verify.go 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4318      +/-   ##
==========================================
- Coverage   40.10%   34.32%   -5.78%     
==========================================
  Files         155      217      +62     
  Lines       10044    15549    +5505     
==========================================
+ Hits         4028     5337    +1309     
- Misses       5530     9520    +3990     
- Partials      486      692     +206     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@steiza steiza marked this pull request as ready for review July 31, 2025 17:05
@steiza steiza requested review from a team as code owners July 31, 2025 17:05
@haydentherapper
Copy link
Contributor

Overall LGTM. Let's hold off on this PR until we land #4316 and #4319, do a pass over the other open PRs, and review the Cosign v3 brainstorm to see if there's anything else we want to get in. Then let's cut a new release of Cosign, hopefully the last v2 release, and then start merging these breaking changes.

@steiza steiza force-pushed the default-protobuf branch from 1326825 to 307f358 Compare August 7, 2025 19:52
@steiza
Copy link
Member Author

steiza commented Aug 7, 2025

So, in some senses this is not a breaking change, in that we've made it so that verify-blob and verify-blob-attestation will "fall back" to trying the old bundle format if they can't parse the provided bundle using the protobuf:

$ cat test.sigstore.json 
{"base64Signature":"MEUCIEjqaXVxJgbngDBIXX9DnZ9yuQBK2Y2dU2C1O74T0RvlAiEA9WI9il4+bHMVtzGl8lxrX3SxCfdg5IMUT90Zk5roOu8="}

Verifies if you explicitly say it's the old bundle format:

$ go run cmd/cosign/main.go verify-blob --bundle=test.sigstore.json --new-bundle-format=false --key=cosign.pub --use-signed-timestamps=false --insecure-ignore-tlog=true ../sigstore-go/examples/sigstore-go-signing/hello_world.txt 
...
Verified OK

... but also verifies if you omit the bundle format (defaults to true):

$ go run cmd/cosign/main.go verify-blob --bundle=test.sigstore.json --key=cosign.pub --use-signed-timestamps=false --insecure-ignore-tlog=true ../sigstore-go/examples/sigstore-go-signing/hello_world.txt 
...
Verified OK

I spent some time looking into providing this fallback behavior for OCI verify commands (verify, verify-attestation) as well. It's technical possible of course, but it would either add quite a few requests to your registry for each verify (essentially doubling the requests) or require a somewhat substantial refactor in order to query once and then pass the results along to pkg/cosign/verify.go functions - what do you think?

@steiza
Copy link
Member Author

steiza commented Aug 7, 2025

There's some issues with how the trusted root file is working in verify - I'll have to take a look later

@steiza
Copy link
Member Author

steiza commented Aug 8, 2025

I couldn't get the scaffolding working with the new bundle format - I think there was some issue with how the trusted root was constructed - but we can update it when we overhaul the scaffolding test.

@steiza
Copy link
Member Author

steiza commented Aug 15, 2025

Okay! With #4346 I think the old scaffolding is working with the new protobuf bundle format. I also added code for verify and verify-attestation to detect if you are using the old signature format and to gracefully fallback. If tests pass, I think this is ready to review.

@haydentherapper
Copy link
Contributor

The one downside with this is that while it's not a breaking change for verification of old metadata, it is a breaking change for verifying new metadata, in that you can't use an old client to verify new signatures. Are we OK with that?

@steiza
Copy link
Member Author

steiza commented Aug 20, 2025

The one downside with this is that while it's not a breaking change for verification of old metadata, it is a breaking change for verifying new metadata, in that you can't use an old client to verify new signatures. Are we OK with that?

I think so. I would hope that an organization would upgrade it's toolchain (for signing and verifying) to a new version at the same time.

If we don't think that's reasonable, the alternative (which I'm okay with) is cutting a last cosign 2.x release before this lands and have this be the start of cosign v3!

…ml; until cosign sign supports new bundle format

Signed-off-by: Zach Steindler <[email protected]>
Signed-off-by: Zach Steindler <[email protected]>
Have `cosign sign` default to true

Signed-off-by: Zach Steindler <[email protected]>
Signed-off-by: Zach Steindler <[email protected]>
Signed-off-by: Zach Steindler <[email protected]>
Signed-off-by: Zach Steindler <[email protected]>
Copy link
Contributor

@haydentherapper haydentherapper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fantastic!

if !c.LocalImage {
ref, err := name.ParseReference(images[0], c.NameOptions...)
if err == nil && c.NewBundleFormat {
newBundles, _, err := cosign.GetBundles(ctx, ref, co)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll make an extra network call with GetBundles - do you think that's fine? Or should we store the bundles it finds and pass those to the verification function? Not sure if that's straightforward though.

Copy link
Member Author

@steiza steiza Sep 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I mention this above:

I spent some time looking into providing this fallback behavior for OCI verify commands (verify, verify-attestation) as well. It's technical possible of course, but it would either add quite a few requests to your registry for each verify (essentially doubling the requests) or require a somewhat substantial refactor in order to query once and then pass the results along to pkg/cosign/verify.go functions - what do you think?

As you can see, I opted to implement increasing the number of requests 😆 While testing / debugging these changes though, I discovered there was already another place in cmd/cosign/cli/verify/verify_attestation.go where we were doing this, in addition to pkg/cosign/verify.go and pkg/oci/remote/write.go. In short, I don't think it's an issue.

Copy link
Contributor

@haydentherapper haydentherapper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meant to approve, just one comment!

}

// Check to see if we are using the new bundle format or not
if !c.LocalImage {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm, this should handle backwards compatibility for verification of either the new or old bundle format?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, so this version of the code has c.NewBundleFormat default to true, so it tests to make sure you aren't using an old format bundle.

The only case that doesn't work here is if you explicitly specify --new-bundle-format=false while pointing it at a new bundle, but I'm not sure how you'd end up in that case.

- name: Verify with cosign
run: |
./cosign verify --rekor-url ${REKOR_URL} --allow-insecure-registry ${demoimage} --certificate-identity https://kubernetes.io/namespaces/default/serviceaccounts/default --certificate-oidc-issuer "https://kubernetes.default.svc.cluster.local"
./cosign verify --trusted-root=${trustedroot} --allow-insecure-registry ${demoimage} --certificate-identity https://kubernetes.io/namespaces/default/serviceaccounts/default --certificate-oidc-issuer "https://kubernetes.default.svc.cluster.local"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--trusted-root shouldn't be necessary here, it's already set for these local services in the cosign initialize step (both the air-gapped version and remote version)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that now that #4347 landed (which I wrote after this pull request) you're right!

I'm going to leave this as-is since this pull request has been going for a month and a half, but I support testing / removing --trusted-root from kind-verify-attestation.yaml.


// TODO: have this default to true as a breaking change
cmd.Flags().BoolVar(&o.NewBundleFormat, "new-bundle-format", false, "expect the signature/attestation to be packaged in a Sigstore bundle")
cmd.Flags().BoolVar(&o.NewBundleFormat, "new-bundle-format", true, "expect the signature/attestation to be packaged in a Sigstore bundle")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not your change, but why is the word "expect" here? The sign command is creating the bundle in a format it decides, not expecting anything of an existing bundle.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think this is just copy/pasted from verify commands - we should change this! But I'm going to leave this as-is to not further increase the scope of this pull request.

@steiza steiza merged commit b952363 into sigstore:main Sep 16, 2025
29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants