-
Notifications
You must be signed in to change notification settings - Fork 50
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
Conversation
…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>
@laurentsimon qq: what is the pupose of testing |
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? |
Gotcha: I can make the command return the outBuilderID as string for now to satisfy the tests (e.g. |
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`.| |
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.
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.
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.
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`.| |
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 wonder if we need this level of details here. I'm worried it will go out of sync with the implementation.
How about:
- 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.
- 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?
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.
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.
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.
Looks really nice!
Since we're at it, I've added a bunch of comments about argument naming. Let me know what you think.
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[]) |
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.
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
...
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 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?
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.
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
... ?
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 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"?
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 now, I think it's easier to organize as build-XYZ
or source-XYZ
of the current options. At least it organizes the options.
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.
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?
Signed-off-by: Asra Ali <asraa@google.com>
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.
LGTM, thanks
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. |
alright. Let's make it happen then. |
Signed-off-by: Asra Ali <asraa@google.com>
Signed-off-by: Asra Ali <asraa@google.com>
@laurentsimon merged your changes on compute digest FN and GCB provenance. Good to merge with slsa-framework/example-package#100? |
LGTM! |
What's |
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 |
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>
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>
Signed-off-by: Asra Ali asraa@google.com
This PR does the following:
verify-artifact
andverify-image
to the CLI Create subcommands for artifact and image verification #205verifiers
function call and the artifact image digest calculation--provenance
to--provenance-path
. See Rename--provenance
to---provenance-path
#93Fixes #205
Fixes #229
Fixes #173
Fixes #93
TODO: