-
Notifications
You must be signed in to change notification settings - Fork 547
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new bundle support to verify-blob
and verify-blob-attestation
#3796
Conversation
Part of sigstore#3139 Signed-off-by: Zach Steindler <[email protected]>
|
||
func verifyNewBundle(ctx context.Context, bundlePath, trustedRootPath, keyRef, slot, certOIDCIssuer, certOIDCIssuerRegex, certIdentity, certIdentityRegexp, githubWorkflowTrigger, githubWorkflowSHA, githubWorkflowName, githubWorkflowRepository, githubWorkflowRef, artifactRef string, sk, ignoreTlog, useSignedTimestamps, ignoreSCT bool) error { | ||
if certOIDCIssuerRegex != "" { | ||
return fmt.Errorf("--new-bundle-format does not support --certificate-oidc-issuer-regexp") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although support is coming soon! sigstore/sigstore-go#236
go.mod
Outdated
github.com/sigstore/rekor v1.3.6 | ||
github.com/sigstore/sigstore v1.8.7 | ||
github.com/sigstore/sigstore-go v0.4.1-0.20240717174219-8554eb6de5ac |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make use of sigstore/sigstore-go#235. Once sigstore/sigstore-go#236 also lands we should consider cutting a numbered release of sigstore-go to include these two changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved - shall we merge all the open dependabot PRs and then cut a new release? (Edit, I created a PR to bump all the deps)
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3796 +/- ##
==========================================
- Coverage 40.10% 37.65% -2.45%
==========================================
Files 155 202 +47
Lines 10044 12571 +2527
==========================================
+ Hits 4028 4734 +706
- Misses 5530 7251 +1721
- Partials 486 586 +100 ☔ View full report in Codecov by Sentry. |
Signed-off-by: Zach Steindler <[email protected]>
return err | ||
} | ||
|
||
newExpiringKey := root.NewExpiringKey(signatureVerifier, time.Time{}, time.Time{}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of scope for this, should we create a non-expiring key as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The terminology here is confusing - despite the name NewExpiringKey
, since the validityPeriodStart
and validityPeriodEnd
will return true for IsZero()
, this key won't actually be treated as expiring.
In the future, if there are cosign CLI flags for specifying the validity period of the key, we could make use of them here!
} | ||
buf := bytes.NewBuffer(payload) | ||
|
||
sev, err := verify.NewSignedEntityVerifier(trustedmaterial, verifierConfig...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Originally, what I had in mind was decomposing the bundle into the CheckOpts
and OCI structs so that we could call VerifyBlobSignature. The concern was a lack of parity between the two verification policies.
Given that this is guarded behind a flag, it wouldn't be a breaking change to have a different verification path. And maybe I'm overthinking this, that there isn't actually a significant gap between the two verification policies - keys was one concern, but it seems like you've fully supported that here.
WDYT, between either using sigstore-go's verification library or continuing to use Cosign's with bundle decomposition?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was the path I originally started going down - decomposing the bundle and using cosign's existing VerifyBlobSignature()
- similar to the technique we used to add signing support. But it's a fair amount of work to decompose both the bundle and the trusted root into the format cosign is expecting, which would look very similar to code that's already in sigstore-go. Since I think we want to eventually get sigstore-go into cosign (and have more parts of cosign use sigstore-go in the future) I jumped ahead a bit in this pull request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, I'm happy to see us cut over now. I've been looking over VerifyBlobSignature
to see if there are any differences that we'd be missing, but I don't see anything concerning.
Online verification for Rekor is missing, but that's a good thing, I want to remove this. Bundles always have inclusion proofs and online lookups by default isn't a great design.
There is no support for verifying with certificate chains bundled in the verification material, but I know that's blocked on support in sigstore-go, and it's simple enough to work around with a trust root file.
Signed-off-by: Zach Steindler <[email protected]>
21d35fb
to
cad0dde
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, thanks for your work on this! Just one tiny comment.
} | ||
buf := bytes.NewBuffer(payload) | ||
|
||
sev, err := verify.NewSignedEntityVerifier(trustedmaterial, verifierConfig...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, I'm happy to see us cut over now. I've been looking over VerifyBlobSignature
to see if there are any differences that we'd be missing, but I don't see anything concerning.
Online verification for Rekor is missing, but that's a good thing, I want to remove this. Bundles always have inclusion proofs and online lookups by default isn't a great design.
There is no support for verifying with certificate chains bundled in the verification material, but I know that's blocked on support in sigstore-go, and it's simple enough to work around with a trust root file.
Signed-off-by: Zach Steindler <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good to merge as-is!
I'd like a little more testing ideally, could we add an e2e test under https://github.com/sigstore/cosign/blob/main/test/e2e_test.go as well? Can do as a follow up if you prefer.
I would say land as-is. I'm already working on a conformance pull request (which has an open question), which we can roll additional e2e tests into as well. |
…sigstore#3796) * Add new bundle support to `verify-blob` and `verify-blob-attestation` Part of sigstore#3139 Signed-off-by: Zach Steindler <[email protected]> * fix error message Signed-off-by: Zach Steindler <[email protected]> * Use sigstore-go v0.5.1 for cert issuer regex support Signed-off-by: Zach Steindler <[email protected]> * Use more specific `WithIntegratedTimestamps` with tlog verification Signed-off-by: Zach Steindler <[email protected]> --------- Signed-off-by: Zach Steindler <[email protected]>
Summary
This pull request is for the second part of #3139: adding protobuf bundle support for
verify-blob
andverify-blob-attestation
.Now that #3752 has landed, you can first generate bundles with something like:
And verify it (with these changes) with something like:
Or do an attestation with something like:
And then verify that attestation with these changes (assuming your identity token came from https://github.com/sigstore-conformance/extremely-dangerous-public-oidc-beacon/), with:
Release Note
NONE - we probably want to finish #3139 (especially the more comprehensive conformance testing!) before we announce this as released.
Documentation
N/A - same as above