-
Notifications
You must be signed in to change notification settings - Fork 49
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
feat: vsa support #777
feat: vsa support #777
Conversation
…passed" Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
…ject digests Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
LGTM.
…--
Best,
Kai Xu
On Wed, Jun 26, 2024 at 10:56 AM Ramon Petgrave ***@***.***> wrote:
@kaixu-google <https://github.com/kaixu-google>
—
Reply to this email directly, view it on GitHub
<#777 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJNUY46DWIXVXROLBQUMNNDZJLJBDAVCNFSM6AAAAABJUVOGUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJRHEZDCMRQGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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.
Looks great, great work on this! Just a few tiny style changes
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[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.
🥳
Signed-off-by: Ramon Petgrave <[email protected]>
accomodate subjects that are not simple-files. | ||
|
||
|
||
The verify-vsa command |
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.
Do we want to warn that this is a dangerous / advanced option that really nobody should be using. In the future we'll have verify-artifact --vsa-path
that will verify the VSA for an artifact (using digest's hash). I don't know how to best discourage usage of this command. Maybe:
- Put this command readme into a sub folder
- Warn in the command hel this shodul not be used unless you know what you're doing
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.
Why do you think this is dangerous? If you get to the point where you have a VSA you need to verify, I assume you should understand what the VSA represents. So maybe adding a link to https://slsa.dev/spec/v1.1/verification_summary#purpose to make sure users understand one?
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.
@laurentsimon Instead of verify-artifact --vsa-path
, I was thinking to continue with verify-vsa path1 path2 ...
, or verify-vsa --artifact-path path1 --artifact-path path2 ...
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 don't think re-using verify-vsa
is consistent with the existing API. We currently use verify-artifact
and verify-image
, so I think it's the right way to build on existing APIs. You can verify an artifact using provenance, or a VSA, or something else. verify-vsa
is a low-level API for the rare use case that the artifact is not available, and should not be used / advertised otherwise.
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.
re: why it's dangerous API. TOCTOU is an example of a vuln https://github.com/slsa-framework/slsa-verifier?tab=readme-ov-file#containers-1. We've been very careful to design the CLI in a way that prevent users from shooting themselves in the foot (well, I suppose they still can :)). Leaving it up to users to calculate a sha is both poor UX (running the CLI now requires computing a hash) and prone to mistakes (not everyone can be an expert)
In general I think of verify-vsa
and verify-provenance
(which does not exist yet) as low-level APIs that verify signature and match content passed by the caller. The safer APIs users should use are the verify-artifact
, verify-image
. Wdut?
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.
OK, I see what you're saying. This seems more like a not ideal UX rather than dangerous, since we are asking for a digest, and the digest should be an immutable reference - if it's not, then it's technically non-compliant with SLSA. If we were to add a comment, I might say that we'd like to refactor this at some point to move VSA verification under verify-artifact
.
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 of the CLI options more like
verify-artifact
actually means "verify-provenance-with-artifact", or "verify-artifact-provenance"
With this thinking, a VSA is not actually a provenance (build provenance). And I'm open to making a new command "verify-artifact-vsa". To avoid the danger of the user not realizing that they're not enjoying the benefits of an actual build provenance.
re: TOCU, you're referring to how verify-image
relies on the user using external tools to calculate digests (docs incorrectly says "tarball")
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.
verify-artifact actually means "verify-provenance-with-artifact", or "verify-artifact-provenance"
That was not the original intention, and that's why the term 'provenance' is not in the command's name. It's intended to verify artifacts with whatever attestation. It so happens the only one currently supported is provenance, but it need not be. If you ever need to verify an artifact with several attestations, you'll be able to do verify-artifact --provenance-path --source-path etc
... unless they are packed into a bundle and you'll likely use --attestations-path
like in npm command.
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.
OK, I see what you're saying. This seems more like a not ideal UX rather than dangerous, since we are asking for a digest, and the digest should be an immutable reference - if it's not, then it's technically non-compliant with SLSA. If we were to add a comment, I might say that we'd like to refactor this at some point to move VSA verification under
verify-artifact
.
just have to be careful that users don't use the non-immutable image for pulling
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
return err | ||
} | ||
// 6. confirm the verificationResult is Passed | ||
if err := confirmVerificationResult(vsa); err != nil { |
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.
nit: be consustent with function names. Other functions are called match*
, this one is called confirm*
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.
Only because, unlike the others, it doesn't compare the VSAs value with any user input.
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.
gotcha. just a nit. up to you :)
Signed-off-by: Ramon Petgrave <[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.
Thanks!
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.
Great work!!
Signed-off-by: Ramon Petgrave <[email protected]>
This reverts commit 9ad9097.
Fixes #542
Adds support for VSAs.
Testing process
added some unit an end-to-end tests
manually invoking
TODOS: