Skip to content
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

fix: fix cert chain validation for verify-blob in non-experimental mode #2256

Merged
merged 5 commits into from Sep 16, 2022

Conversation

asraa
Copy link
Contributor

@asraa asraa commented Sep 15, 2022

Signed-off-by: Asra Ali asraa@google.com

Summary

  • fix: Pulls Fulcio root and intermediate when --certificate-chain is not passed into verify-blob.

In non-experimental mode, we incorrectly only loaded Fulcio roots to verify against when certRef == "".

When a certRef != "" in non-experimental mode, like, user provides cert with offline bundle without specifying a custom cert chain, then we would NOT load in the Fulcio roots. This would cause certificate validation failure.

Instead, whenever certChain == "" we will load in fulcio roots in non-experimental mode, either if you provide a cert or a bundle.

Release Note

  • fix: Pulls Fulcio root and intermediate when --certificate-chain is not passed into verify-blob. The v1.12.0 release introduced a regression: when COSIGN_EXPERIMENTAL was not set, cosign verify-blob would check a --certificate (without a --certificate-chain provided) against the operating system root CA bundle. In this release, Cosign checks the certificate against Fulcio's CA root instead (restoring the earlier behavior).

Documentation

Signed-off-by: Asra Ali <asraa@google.com>
@asraa
Copy link
Contributor Author

asraa commented Sep 15, 2022

Should add test validating that we will succeed when certRef != "" in non-experimental mode. I think that's currently missing. One sec.

if err != nil {
return fmt.Errorf("getting Fulcio intermediates: %w", err)
}
}
co.SigVerifier, err = cosign.ValidateAndUnpackCert(cert, co)
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we handle else for when the cert chain is set? Otherwise, the certificate wouldn't validate if it's been signed by a non-fulcio pki

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good catch!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

lemme see if I can also add a test here.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hm...I think it's pretty unexpected that --certificate-chain would mean "accept whatever cert was at the root of the chain."

This is part of why I think an explicit --certificate-root flag would be a good idea.

Copy link
Contributor

Choose a reason for hiding this comment

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

We do document the the chain is the intermediates and root -

"path to a list of CA certificates in PEM format which will be needed "+
"when building the certificate chain for the signing certificate. "+
"Must start with the parent intermediate CA certificate of the "+
"signing certificate and end with the root certificate")

Copy link
Contributor

Choose a reason for hiding this comment

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

Yea, let's. It's a bit unclear to me what should be the right behavior here, especially if I provide both a sigstore root and certificate chain.

Copy link
Contributor

Choose a reason for hiding this comment

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

The behavior here should match 1.11.x (the more significant change is around checking expiration)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If someone could help me update the release notes to close this out, that'd be great. I added one in. I'm not sure if anything breaks.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hm I don't see anything under "Release Notes" in the PR description.

Maybe:

The v1.12.0 release introduced a regression: when COSIGN_EXPERIMENTAL was not set, cosign verify-blob would check a --certificate (without a --certificate-chain provided) against the operating system root CA bundle. In this release, Cosign checks the certificate against Fulcio's CA root instead (restoring the earlier behavior).

I think we should have a summary of the current behavior (as opposed to a diff, in the release note) somewhere too; maybe that's what we can hash out in #2254

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, I put it in the summary instead. Moved, but feel free to edit.

Sg, I'll add a longer explanation

Signed-off-by: Asra Ali <asraa@google.com>
@asraa
Copy link
Contributor Author

asraa commented Sep 15, 2022

Just added a test verifying that certRef provided without explicit intermediate succeeds against the fulcio roots.

@codecov-commenter
Copy link

codecov-commenter commented Sep 15, 2022

Codecov Report

Merging #2256 (0a2e6e7) into main (f43839b) will increase coverage by 0.15%.
The diff coverage is 42.85%.

@@            Coverage Diff             @@
##             main    #2256      +/-   ##
==========================================
+ Coverage   28.40%   28.56%   +0.15%     
==========================================
  Files         131      131              
  Lines        7832     7855      +23     
==========================================
+ Hits         2225     2244      +19     
+ Misses       5309     5305       -4     
- Partials      298      306       +8     
Impacted Files Coverage Δ
cmd/cosign/cli/verify/verify_blob.go 45.26% <42.85%> (+0.35%) ⬆️
cmd/cosign/cli/verify/verify.go 5.97% <0.00%> (+2.61%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

cmd/cosign/cli/verify/verify_blob.go Show resolved Hide resolved
cmd/cosign/cli/verify/verify_blob_test.go Outdated Show resolved Hide resolved
cmd/cosign/cli/verify/verify_blob_test.go Outdated Show resolved Hide resolved
if err != nil {
return fmt.Errorf("getting Fulcio intermediates: %w", err)
}
}
co.SigVerifier, err = cosign.ValidateAndUnpackCert(cert, co)
Copy link
Contributor

Choose a reason for hiding this comment

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

Hm...I think it's pretty unexpected that --certificate-chain would mean "accept whatever cert was at the root of the chain."

This is part of why I think an explicit --certificate-root flag would be a good idea.

Signed-off-by: Asra Ali <asraa@google.com>
Signed-off-by: Asra Ali <asraa@google.com>
cmd/cosign/cli/verify/verify_blob_test.go Outdated Show resolved Hide resolved
if err != nil {
return fmt.Errorf("getting Fulcio intermediates: %w", err)
}
}
co.SigVerifier, err = cosign.ValidateAndUnpackCert(cert, co)
Copy link
Contributor

Choose a reason for hiding this comment

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

If we're sure that this matches the behavior from v1.11.x, and we explain it more clearly in the help text, I'm okay with dealing with this problem later.

Signed-off-by: Asra Ali <asraa@google.com>
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.

thanks!

@asraa asraa enabled auto-merge (squash) September 15, 2022 21:44
@asraa asraa merged commit 63fe875 into sigstore:main Sep 16, 2022
@github-actions github-actions bot added this to the v1.13.0 milestone Sep 16, 2022
@cpanato
Copy link
Member

cpanato commented Sep 16, 2022

@asraa @dlorenc should we release a 1.12.1 patch?

@haydentherapper
Copy link
Contributor

@cpanato as soon as possible I think. Release notes should be specified in the PR description

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.

None yet

6 participants