-
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
refactor: share logic between verify-blob, verify, and verify-attestation #2461
Conversation
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.
Going to just move the blob verifies to the package. That will further simplify.
These changes look good to me.
This depends on our choice for blob signing. If we choose to generate two bundles. How do we expect the verification to work ? |
I think the same as OCI. Here's a flow:
|
Okay, let's get these changes in main. |
Just updated to fix the tests. I had to do two things:
|
@asraa Please, rebase your branch. I have added some changes to use a flag skip-tlog-verify as proposed. It also supports both validations tsa and rekor. Let me know if you find any issue so I can help. |
SG, just fixed the public key comparisons for OCI 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.
@hectorj2f @priyawadhwa @znewman01 @kpk47 i would appreciate a review!
Some of the verification logic is now clobbered with a few PRs merged into main, and I will put out a follow-up & more tests (particularly: if you skip TLOG verify and use a TSA you also end up skipping the short-lived expiry validation now)
signature string | ||
key []byte | ||
cert *x509.Certificate | ||
bundlePath string | ||
// If online lookups to Rekor are enabled | ||
experimental bool |
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.
Most of these tests set the experimental flag, but we've begun to remove it - should we remove it from the tests too? (Separate refactor prolly)
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.
Yeah, I'll add in a separate PR: it actually does nothing now :)
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.
LGTM, we have simplified the verification logic a lot.
Signed-off-by: Asra Ali <asraa@google.com> fix all remaining issues Signed-off-by: Asra Ali <asraa@google.com> fix all tests Signed-off-by: Asra Ali <asraa@google.com> fix lint Signed-off-by: Asra Ali <asraa@google.com> fix lint Signed-off-by: Asra Ali <asraa@google.com> lint Signed-off-by: Asra Ali <asraa@google.com> fix test Signed-off-by: Asra Ali <asraa@google.com>
Codecov Report
@@ Coverage Diff @@
## main #2461 +/- ##
==========================================
- Coverage 30.96% 30.32% -0.65%
==========================================
Files 139 139
Lines 8635 8475 -160
==========================================
- Hits 2674 2570 -104
+ Misses 5600 5552 -48
+ Partials 361 353 -8
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Signed-off-by: Asra Ali <asraa@google.com> fix Signed-off-by: Asra Ali <asraa@google.com>
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 owe you a more detailed pass, just a couple things that jumped out at first)
|
||
// Require a certificate/key OR a local bundle file that has the cert. | ||
if options.NOf(c.KeyRef, c.CertRef, c.Sk, c.BundlePath) == 0 { |
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.
Should this be != 1
?
Oh, I guess not because BundlePath
isn't really a full "bundle" yet. That's annoying.
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.
Yeahhhh. This is super annoying because in sign-blob, you can produce a bundle path (to store the sig) INDEPENDENT of the tlog upload. If you don't upload to the tlog, then the bundle will ONLY contain the signature (and NOT the public key).
This was tested in the e2e tests... so I had to modify this. Basically: in some cases you legit pass in a --key
AND a --bundle
that stores the signature.
if co.RootCerts == nil { | ||
co.RootCerts = x509.NewCertPool() | ||
} | ||
co.RootCerts.AddCert(chain[len(chain)-1]) |
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.
Does this mean that if we pass a chain, we automatically trust it?
That feels wrong to me.
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.
Before the refactoring, this was a way to pass in a chain as an alternative to fetching from the TUF root. Without a chain, we'd default to the TUF metadata, otherwise we'd use the chain passed in.
One bit of feedback is there's a lot of places we're checking chain != nil
or c.CertChain != ""
, so it's a little hard to quickly see exactly where we're getting the trust root from.
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 Zack's point, there are three ways you could pass a root in (this is also all applicable to intermediates):
- SIGSTORE_ROOT_FILE, which will get read in in fulcio.GetRoots
- tuf (either the sigstore tuf root or a self-hosted one), read in in fulcio.GetRoots
- Passing in the cert chain here
I'm not opposed if we want to force the user to set SIGSTORE_ROOT_FILE, as this supports both roots and intermediates (added in #1749). I don't recall why this was added this way - likely just a product of iterative development and some overlapping features haha.
That said, I'm also not opposed to supporting the chain flag too. It really is no different than SIGSTORE_ROOT_FILE, but if it makes things easier, we could drop it. Just wanna make sure we don't lose any supported features.
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.
Yeah: this is because in the BLOB case you pass in the cert chain, so you DO trust it "out of band".
In the OCI case, the cert chain is provided on the registry. This was the only way I could get parity on the behavior. the cert chain passed here does represent the full trust chain.
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.
One bit of feedback is there's a lot of places we're checking chain != nil or c.CertChain != "", so it's a little hard to quickly see exactly where we're getting the trust root from.
Just realized you mentioned this so I went and checked. There's only one place that c.CertChain
is used, and that's to populated chain
-- after that everything is populated from chain
. Cleaned that up.
If we treat --cert-chain
as a separate option rather than checking when --certificate is provided OR if --bundle is provided, I just check independently once. Then I add as the annotation when a certificate is used (whether populated from --certificate or --bundle)
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.
LMK if there's anything else here, or we can resolve.
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.
Filed #2472 as a follow up
cmd/cosign/cli/verify/verify_blob.go
Outdated
} | ||
} | ||
opts = append(opts, static.WithCertChain(certPEM, chainPEM)) |
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.
What happens if chain
is not set, in the case of using the default TUF chain here? chainPEM
will not be set, is that an issue?
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.
Hm, in
Line 644 in 0827726
if len(chain) > 0 { |
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 think the purpose was that the roots were loading in earlier, and if you have an intermediate in your chain, we'd automatically populate an intermediate pool. Had to review 7402eb4 where I added this
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 bet this was added originally because we didn't have the intermediate in the TUF root, so the idea was that we'd fetch the intermediate from the chain automatically (and we treated the intermediate as "untrusted", just a part of chain building)
(Note to myself, write better PR messages)
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 think the purpose was that the roots were loading in earlier, and if you have an intermediate in your chain, we'd automatically populate an intermediate pool. Had to review 7402eb4 where I added this
Exactly. Before we actually reset intermediates, but in using blobs, we actually wanted to preserve the TUF roots that were populated already.
89fdc26
Signed-off-by: Asra Ali <asraa@google.com>
@haydentherapper @znewman01 lemme know if you have time to do another pass! since it's working around the verification logic, would love to have it in. I have a follow-up issue on cleaning up the verification main method. |
Signed-off-by: Asra Ali asraa@google.com
validityTime
with the TSA)Follow-ups:
Summary
Release Note
Documentation