-
Notifications
You must be signed in to change notification settings - Fork 53
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: support oci image verification #147
Conversation
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[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.
What is the process to verify the attached binaries?
The goal is to make sure the e2e tests are reliable.
Yes @naveensrinivasan I'm still trying to figure out a testing strategy
I don't understand the question. Binaries are already e2e tested.
Yeah. Ideally I'd be able to attach manifests for OCI images and use those to verify. I will probably need to implement a fake registry and a fake signed image for cosign. do you have other ideas? |
How were these specific binaries already e2e tested? I am trying to understand, so pardon my ignorance. |
🤦 Now, I see them as renamed and not new binaries. Thanks, it makes sense. I thought these were new binaries. |
main.go
Outdated
@@ -82,7 +92,13 @@ func main() { | |||
"print the verified provenance to std out") | |||
flag.Parse() | |||
|
|||
if provenancePath == "" || artifactPath == "" || source == "" { | |||
if (provenancePath == "" || artifactPath == "") && ociImageRef == "" { |
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 feel like we should have different commands for containers vs. artifacts
The combinations of how flags are used isn't really very user friendly and I feel like it will just get worse over 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.
...not that I expect that to be implemented in this PR. Just a general comment.
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.
For v2, I'll try to write a one-pager on the SLSA verifier API. There are a few issues on this (#180) and I am worried without writing it up first I'll get it wrong.
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.
Just to be clear, I was simply thinking something like slsa-verifier verify-artifact ...
and slsa-verifier verify-image ...
something like that. Right now it's down to the combination of what flags users use. Commands allow us to have different flags for different CLI commands.
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.
Ah, yes I agree too we should have sub-commands separating the two.
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.
SGTM
Signed-off-by: Asra Ali <[email protected]>
Currently working with example-test packages
For some reason, |
Got tests in. Waiting for the queue of PRs #187 and then I'll implement the |
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
@ianlewis @laurentsimon This is ready now. I had to make a few changes for testing -- remote and local images behave slightly different. See the I will make an issue to add more testing: malicious tests, tag verification. Just wanted to start the functionality. |
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 overall. Excited to see this one land!!
cli/slsa-verifier/main.go
Outdated
) | ||
|
||
func main() { | ||
flag.StringVar(&builderID, "builder-id", "", "EXPERIMENTAL: the unique builder ID who created the provenance") | ||
flag.StringVar(&provenancePath, "provenance", "", "path to a provenance file") | ||
flag.StringVar(&artifactPath, "artifact-path", "", "path to an artifact to verify") | ||
flag.StringVar(&artifactReference, "artifact-reference", "", "reference to an OCI image to verify") |
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.
so are we giving up on the idea of verify-artifact
and verify-container
subcommand? What was decided in the end?
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 we should, should I do that in this PR though? If it's pretty easy to review I can split the commands
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.
up to you, I don't mind either way
cli/slsa-verifier/main.go
Outdated
) | ||
|
||
func main() { | ||
flag.StringVar(&builderID, "builder-id", "", "EXPERIMENTAL: the unique builder ID who created the provenance") | ||
flag.StringVar(&provenancePath, "provenance", "", "path to a provenance file") | ||
flag.StringVar(&artifactPath, "artifact-path", "", "path to an artifact to verify") | ||
flag.StringVar(&artifactReference, "artifact-reference", "", "reference to an OCI image to verify") |
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 curious: is "reference" is standard term in container world?
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.
yes, it means repository:tag. technically it also supports the actual digest, so maybe I should say -artifact-image (and image reference resolution will be implicit)?
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 see. If this is a common term, then it's fine. artifact-image would also work for me.
/cc @ianlewis any thoughts?
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.
Changed to artifact-image for now. Leaving unresolved for feedback from Ian
Signed-off-by: Asra Ali <[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. Left a few comments.
crname "github.com/google/go-containerregistry/pkg/name" | ||
) | ||
|
||
var GetImageDigest = func(image string) (string, error) { |
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.
Note: would this break if we verify in parallel different images that require changing this global variable?
I don't think we're going to need that any time soon.. unless the unit tests have to.
I wonder whether we this should be a func GetImageDigest()
and have an interface that this function implement in a structure. This way anyone who needs to update the function can create their structure and set the function to whatever they want. By default, the function would be the one declared in this file.
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.
Hmmm The purpose of this global is just for testing -- only testing will use the modified vars (and always will)
I wonder whether we this should be a func GetImageDigest() and have an interface that this function implement in a structure.
Actually, that can work. We can do a file-based impl and a registry-based implementation of the container. Then we can instantiate based on the params (was image str a local file or a container reference)
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.
It's fine to do that in a follow-up PR. Up to you.
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali [email protected]
Support OCI image verification in the GHA verifier. OCI images can be verified using
Added initial testing, for valid signatures, invalid builder IDs and invalid source repositories.