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

refactor: add subcommands and separate functionality from artifacts a… #231

Merged
merged 12 commits into from
Sep 6, 2022

Conversation

asraa
Copy link
Contributor

@asraa asraa commented Aug 23, 2022

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

This PR does the following:

Fixes #205
Fixes #229
Fixes #173
Fixes #93

TODO:

  • Update usage of verifier at HEAD in example-package

…nd images

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

remove

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

fix

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

update build cmd

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

asraa commented Aug 23, 2022

@laurentsimon qq: what is the pupose of testing outBuilderID from the main CLI? it was never returned or output before

@laurentsimon
Copy link
Contributor

@laurentsimon qq: what is the pupose of testing outBuilderID from the main CLI? it was never returned or output before

I think to display it (someday), the same way that we display information about repo / commit hash. More work is needed to decide what format we need to display it, though.

Wdut?

@asraa
Copy link
Contributor Author

asraa commented Aug 23, 2022

More work is needed to decide what format we need to display it, though.

Gotcha: I can make the command return the outBuilderID as string for now to satisfy the tests (e.g. cmd.Exec(ctx, args) returns (string, error) Later we can formalize on that output.

@laurentsimon
Copy link
Contributor

More work is needed to decide what format we need to display it, though.

Gotcha: I can make the command return the outBuilderID as string for now to satisfy the tests (e.g. cmd.Exec(ctx, args) returns (string, error) Later we can formalize on that output.

SG

Signed-off-by: Asra Ali <asraa@google.com>
README.md Outdated
| Option | Description |
| --- | ----------- |
| `source` | Expects a source, for e.g. `github.com/org/repo`. This option verifies that `ConfigSource` and `Materials` of the SLSA provenance contain the expected `source`. |
| `branch` | Expects a `branch` like `main` or `dev`. Verifies this against the `github_ref` in the SLSA provenance when the `github_ref_type` is a `branch`, or the `base_ref` or `target_commitish` when a `tag`.|
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's add that is not supported for all triggers. It depends on GH payload. If trigger is on an annotated tag, it's not available. If a tag is not annotated, but the tag is made not from the HEAD of a branch (say, an older commit from main), it's not supported either.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, not supported on manual workflow_dispatch (-workflow-input is needed instead and depends on each project).

README.md Outdated
| Option | Description |
| --- | ----------- |
| `source` | Expects a source, for e.g. `github.com/org/repo`. This option verifies that `ConfigSource` and `Materials` of the SLSA provenance contain the expected `source`. |
| `branch` | Expects a `branch` like `main` or `dev`. Verifies this against the `github_ref` in the SLSA provenance when the `github_ref_type` is a `branch`, or the `base_ref` or `target_commitish` when a `tag`.|
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we need this level of details here. I'm worried it will go out of sync with the implementation.
How about:

  1. Keep the documentation simpler in this README. Maybe we can have a table that explains which options are supported for which builder, and that the branch option is brittle.
  2. If we want more detailed doc, maybe have a README under verifiers/internal/<builder>/README.md. There is still a risk of getting out of sync, of course....

Anything we could do better that what I'm proposing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Simplified the README.md. I mostly want to make sure that there's documentation for what the options should look like, with some examples in this PR

Eveneually we should have some documentation somewhere of how verification works for specific builders.

Copy link
Contributor

@laurentsimon laurentsimon left a comment

Choose a reason for hiding this comment

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

Looks really nice!
Since we're at it, I've added a bunch of comments about argument naming. Let me know what you think.

.github/config-release.yml Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated
--source string expected source repository that should have produced the binary, e.g. github.com/some/repo
--tag string [optional] expected tag the binary was compiled from
--versioned-tag string [optional] expected version the binary was compiled from. Uses semantic version to match the tag
--workflow-input map[] [optional] a workflow input provided by a user at trigger time in the format 'key=value'. (Only for 'workflow_dispatch' events). (default map[])
Copy link
Contributor

Choose a reason for hiding this comment

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

this would (maybe ?) be renamed to build-inputs if we follow the build / source / provenance requirements's naming convention. I'm not 100% sure build-input is better than workflow-input... maybe build-workflow-input...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think build-inputs is an accurate term for workflow dispatch inputs, but i wonder if that would get conflated with other types of inputs.

For GHA builders: the only inputs to workflows is through workflow dispatch inputs. But what about inputs to the trusted builders themselves?

Copy link
Contributor

@laurentsimon laurentsimon Aug 25, 2022

Choose a reason for hiding this comment

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

fully agreed. That's why I hinted at -build-workflow-inputs., to make it more explicit that it's for (GitHub) workflows. Not sure this is enough. Is it possible to name the option after the type of builders that support it? -build-gha-inputs. I'm making the name up...

Maybe -build-input would be enough if the content is formatted, like -build-input workflow_dispatch:bla=bla... ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think formatting inputs is brittle and if we are considering that it is likely not good. If they are builder specific, I think some options are already interpreted slightly different -- so build-input for GHA could mean workflow inputs.

OTOH I don't know how to distinguish between types of build inputs for a single builder. If someone wants to check on inputs to the trusted builders, can they access the provenance, since that is more of a "recipe"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For now, I think it's easier to organize as build-XYZ or source-XYZ of the current options. At least it organizes the options.

Copy link
Contributor

Choose a reason for hiding this comment

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

SGTM.

OTOH I don't know how to distinguish between types of build inputs for a single builder. If someone wants to check on inputs to the trusted builders, can they access the provenance, since that is more of a "recipe"?

fair enough. Let's start with that then. I am not even sure GCB supports "input", since it's just a webhook.

@ianlewis any objection the direction we're taking here?

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
cli/slsa-verifier/verify/verify_image.go Outdated Show resolved Hide resolved
cli/slsa-verifier/verify/verify_image.go Outdated Show resolved Hide resolved
Copy link
Contributor

@laurentsimon laurentsimon left a comment

Choose a reason for hiding this comment

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

LGTM, thanks

How do we handle merging this PR? Do we merge or wait for the GCB release to be cut?

cli/slsa-verifier/verify/options.go Outdated Show resolved Hide resolved
@asraa
Copy link
Contributor Author

asraa commented Sep 1, 2022

How do we handle merging this PR? Do we merge or wait for the GCB release to be cut?

Given that GCB is breaking too, I think it would be good to merge all in one. That way GCB verification ONLY works with these new CLI arguments, and GCB folks won't have to deal with a breaking API change.

@laurentsimon
Copy link
Contributor

alright. Let's make it happen then.

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

asraa commented Sep 6, 2022

@laurentsimon merged your changes on compute digest FN and GCB provenance. Good to merge with slsa-framework/example-package#100?

@laurentsimon
Copy link
Contributor

LGTM!

@laurentsimon
Copy link
Contributor

What's FN?

@asraa
Copy link
Contributor Author

asraa commented Sep 6, 2022

What's FN?

FN is the compute digest FN you had earlier in the GCB support -- I think we will remove with a better container interface, but was needed to swap in for testing

It's not exposed as a CLI option, but exposed as part of the library right now

@asraa asraa merged commit ff0ced4 into slsa-framework:main Sep 6, 2022
mihaimaruseac added a commit to mihaimaruseac/slsa-verifier that referenced this pull request Dec 28, 2022
One part that is missing in the output if invocation is wrong is that
there is no indication that user has to pass path to a file
(artifact/image).

The remaining potential errors from slsa-framework#173 are handled via slsa-framework#231.

Found while looking at slsa-framework#174.

Signed-off-by: Mihai Maruseac <mihaimaruseac@google.com>
This was referenced Dec 28, 2022
asraa pushed a commit that referenced this pull request Dec 28, 2022
One part that is missing in the output if invocation is wrong is that
there is no indication that user has to pass path to a file
(artifact/image).

The remaining potential errors from #173 are handled via #231.

Found while looking at #174.

Signed-off-by: Mihai Maruseac <mihaimaruseac@google.com>

Signed-off-by: Mihai Maruseac <mihaimaruseac@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants