Action to install/run the verifier

[laurentsimon]

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:

• actions/install
• actions/run with a set of inputs + runs on PR. (Will use actions/install internally as well)

Note that if we manage to have debian, Windows and OSX packages ,the actions/install is greatly simplified

Thought?

[laurentsimon]

Both ko-build/ko#730 (comment) and docker/compose#9702 (comment) have expressed interest in this Action, even as part of the release process.
Here's a plan for v1:

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:

• The semVer will be identical to the verifier, which is a good thing
• Create actions/install to install the verifier. Users can start using the CLI right away.

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 /usr/bin/ and update the GITHUB_ENV if necessary. Users will then be able to run slsa-verifier <>.

In terms of implementation, a simple shell script should suffice.

Wdut?

[asraa]

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:

+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.

We will pull the binary, verify its hash, add it to /usr/bin/ and update the GITHUB_ENV if necessary.

If it lives in this repo anyway, can it build from source? Checkout the tag and build.
I actually think I'm proposing this as a strawman. It is better to pull the binary from GH releases, since paths may change in source for the build.

[laurentsimon]

I'll start with binaries then. If anyone has objections, please reply

[laurentsimon]

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

• build is reproducible OR
• we need to create the release via another workflow (say, wokflow_dispatch), and then hardcode the resulting hash into the code before doing the release.

Second option should work, but it a little annoying. I think that's basically what we'd do if we had a separate repo.

[laurentsimon]

Note to myself: use code docker/compose#9702

[asraa]

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

I'm confused -- can the action script do this:

1. Download the latest release from gh release
2. Get checksum, match with the committed sha's in SHA256SUM.md

Even better, we can also download the latest provenance from the gh release and verify that with local build of the source.

[laurentsimon]

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:

1. Use a verifier binary at a certain version that we download with a hash verification
2. Use this verifier to verify the correct verifier binary based on the hash / version the action is pinned to.

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 @v2, but I think this means we need to force push new tags. AFAIK, GH does not fetch the latest version, it just fetches the tag so we're responsible for force pushing the latest @v2.x.y into @v2 during release.

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

[asraa]

AH right, scratch latest release. Agree with using a certain version

One issue is that if users don't want pinning, they should be able to use @v2, but I think this means we need to force push new tags. AFAIK, GH does not fetch the latest version, it just fetches the tag so we're responsible for force pushing the latest @v2.x.y into @v2 during release.

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 vX.Y.Z)? So I guess the GH action won't know how to resolve to the latest minor version of the release? Why would they end up pinning to a version that doesn't exist? I assume dependabot will only update when a new release is pushed

[laurentsimon]

The GH actions actions/bla@v2 are typically pinned to a major version by users, so I expect users would expected us to support it to. If we make it too hard to use floating versions, some users may be reluctant to install - they don't want to receive PR to bump versions.

[asraa]

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?

[asraa]

Update the following repos when complete:

• github.com/google/ko
• https://github.com/google/go-containerregistry

[laurentsimon]

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 apt package could break users if more recent major versions take precedence during installs and it breaks backward compatibility

[kpk47]

I've created a pull request with a POC for the installer action at #233. Please take a look.

[laurentsimon]

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)

[laurentsimon]

I tested (https://github.com/laurentsimon/slsa-on-github-test/blob/main/.github/workflows/verifier-action.yaml#L11):

uses: slsa-framework/slsa-verifier/actions/installer@v1.4.1

and it gave me the following error: Error: An error occurred trying to start process '/usr/bin/bash' with working directory '/home/runner/work/slsa-on-github-test/slsa-on-github-test/actions/installer'. No such file or directory

@kpk47 can you take a look?

[laurentsimon]

I think the problem is with this line https://github.com/slsa-framework/slsa-verifier/blob/main/actions/installer/action.yml#L24
It's checking out the repository in the context of the caller, so it's not checking our the slsa-verifier repo. We need to read / parse the GITHUB_ACTION_REF like we do in https://github.com/slsa-framework/slsa-verifier/blob/main/actions/installer/src/index.ts#L97 and pass it as argument to the checkout.

@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.

[laurentsimon]

Let me create a new issue for this breakage and close this issue.

[developer-guy]

Update the following repos when complete:

• github.com/google/ko
• google/go-containerregistry

• github.com/google/ko
• google/go-containerregistry

[laurentsimon]

We have not published it yet, we'd like a bit more eye on it and early testers before cutting a release for it :-)
The Action will complain if it's not referenced at a release tag or hash.