-
Notifications
You must be signed in to change notification settings - Fork 48
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
Action to install/run the verifier #95
Comments
Both ko-build/ko#730 (comment) and docker/compose#9702 (comment) have expressed interest in this Action, even as part of the release process. First, we need to decide where the action lives. In this repo, or a different repo. I am in favor of adding the actions in this repo because:
Later, we can create an action to also verify. So what I'm proposing will let users install the verifier via: uses: slsa-framework/slsa-verifier/actions/install No options to start with, it will install the same version as asked by the user. We will pull the binary, verify its hash, add it to In terms of implementation, a simple shell script should suffice. Wdut? |
+1, releasing a new action should be the same as releasing a new version of the CLI tool. It's a little iffy for the service code because that may have distinct features, but not likely that much Yes, let's start with a binary installation. An action to verify is a little harder, esp since we haven't settled on required opts anyway.
If it lives in this repo anyway, can it build from source? Checkout the tag and build. |
I'll start with binaries then. If anyone has objections, please reply |
I think there is a chicken-and-egg problem. We need to hardcode the expected hash of the verifier. But to know the hash, we need to release and build. I think we need to be ensure the
Second option should work, but it a little annoying. I think that's basically what we'd do if we had a separate repo. |
Note to myself: use code docker/compose#9702 |
I'm confused -- can the action script do this:
Even better, we can also download the latest provenance from the gh release and verify that with local build of the source. |
Downloading the latest release goes against the idea of pinning, so I was trying to avoid that; or at least make it possible for users to pin if they want. There's another way to do it:
I was also trying to avoid downloading the fetching the SHASUM256.md because it's over some TLS connection we cannot pin. (that's just hardening, and maybe naive.. since we download repositories / etc this way anyway). I think what I'm proposing is similar to what we do for the builders when we download them, https://github.com/slsa-framework/slsa-github-generator/blob/main/.github/actions/generate-builder/builder-fetch.sh One issue is that if users don't want pinning, they should be able to use If we decide to use the SHA256SUM.md file, we could resolve the version / hash, download it and verify its hash as you suggest. One caveat, I think, is that we'd run into the chicken-and-egg problem here: when checking out the repository, it would not have the checksum we're interested in for the version because we update the file after we release. Note that we don't use the SHA256SUM.md when downloading builders, so we need to discuss if we think this is acceptable or not. And we could re-use the same code. Let's discuss more |
AH right, scratch latest release. Agree with using a certain version
Not sure I understand. Do you mean when users don't want to pin either at all or to one of our release tags (currently |
The GH actions |
Oh, understood, thanks! I went to go read GitHub's docs on releasing GHA, they actually point to this action that force pushes major tags: https://github.com/github-developer/javascript-action/blob/963a3b9a9c662fd499419a240ed8c49411ff5add/.github/workflows/publish.yml#L25 Maybe it's not so bad to force push major and minor version tags? |
Update the following repos when complete: |
Note: we need to discuss further if we want to support floating tags. It's additional complexity. Also, we could instead try to create an Ubuntu package (#17), although this seems to not offer "pinning" unless we can make our builds reproducible. One additional advantage of the Action is that it lets user select the version they want. I think an |
I've created a pull request with a POC for the installer action at #233. Please take a look. |
fyi, there seems to be some recommendation on action releases https://docs.github.com/en/actions/creating-actions/about-custom-actions#using-tags-for-release-management (had not seen it before) |
I tested (https://github.com/laurentsimon/slsa-on-github-test/blob/main/.github/workflows/verifier-action.yaml#L11):
and it gave me the following error: @kpk47 can you take a look? |
I think the problem is with this line https://github.com/slsa-framework/slsa-verifier/blob/main/actions/installer/action.yml#L24 @kpk47 can you make the changes? Can you also add some scheduled workflow run to test the verifier (pinned by hash and tag) in example-package? I think you'l need to list the version dynamically and use script injections to create the list of jobs. |
Let me create a new issue for this breakage and close this issue. |
|
We have not published it yet, we'd like a bit more eye on it and early testers before cutting a release for it :-) |
Users who pull in binaries in CI may want to verify the binary's provenance.
For example, google/ko have an Action to install their binary, and it's cumbersome for them to maintain a script to download our verifier, verify it, and run it on their binary
What could be useful is to build an Action to install our verifier and verify a binary with a set of arguments provided by the user. It would also be useful to be able verify PRs from renovatebot / dependabot: or example, an update from a container image base like distroless could be verified using a public policy.
Maybe we need 2 actions:
Note that if we manage to have debian, Windows and OSX packages ,the
actions/install
is greatly simplifiedThought?
The text was updated successfully, but these errors were encountered: