Setup action v0.2.1 failing on GitHub Enterprise Server

[palloberg]

Hi.

When running on a self hosted GitHub Enterprise Server (GHES) the new version of setup-trivy is failing because it's using the checkout action without allowing the token and github-server-url to be overridden. In that case it tries to check out contrib/install.sh from aquasecurity/trivy on the local GHES instead of from https://github.com/aquasecurity/trivy.

Updating setup-trivy (and the trivy-action) with optional parameters for token and github-server-url and passing those to actions/checkout would probably make it compatible with GHES as well (although more config would be needed for users of the action on GHES).

[palloberg]

Alternatively fetching the install.sh from https://raw.githubusercontent.com/aquasecurity/trivy/refs/heads/main/contrib/install.sh (or https://raw.githubusercontent.com/aquasecurity/trivy/refs/tags/SOMETAG/contrib/install.sh when another version than latest is requested) would bypass the whole authentication problem.

[m-breitbach]

Since recently, we have a similar problem on our GHES, also with the checkout step. In our case, the default branch cannot be determined by the checkout action, I believe because it is operating on github.com URLs.

[DmitriyLewen]

Hello @palloberg @m-breitbach
Unfortunately, i don't have GHES runner and my self-hosted runner works correctly - https://github.com/DmitriyLewen/test-trivy-action/actions/runs/11380381891

But i investigated this issue and looks like we always need to use http://github.com as github-server-url.
It works for me - https://github.com/DmitriyLewen/test-trivy-action/actions/runs/11380839756/job/31660961664

Can you test these changes with GHES?
use commit from my fork (uses: DmitriyLewen/setup-trivy@108c12b3f1803ed4e0e9780fb857f6b00946cb56)

with optional parameters for token and github-server-url

trivy is a public repository. I hope rewriting token doesn't break action/checkout.

We probably don't need to add input for github-server-url, since in all cases action/checkout in setup-trivy should connect to the github.com server.
we will explicitly indicate this server and that will be enough

[palloberg]

Hi @DmitriyLewen. Thanks for looking into this.

Hello @palloberg @m-breitbach Unfortunately, i don't have GHES runner and my self-hosted runner works correctly - https://github.com/DmitriyLewen/test-trivy-action/actions/runs/11380381891

But i investigated this issue and looks like we always need to use http://github.com as github-server-url. It works for me - https://github.com/DmitriyLewen/test-trivy-action/actions/runs/11380839756/job/31660961664

Can you test these changes with GHES? use commit from my fork (uses: DmitriyLewen/setup-trivy@108c12b3f1803ed4e0e9780fb857f6b00946cb56)

For GHES the checkout action is using the hostname of the local GHE server ("the same instance that the workflow is running from unless specified" is what the docs there say), so doing as you did in your fork and hard-coding it to https://github.com should do the trick.

with optional parameters for token and github-server-url

trivy is a public repository. I hope rewriting token doesn't break action/checkout.

When running on GHES the token created for the workflow is not valid on GitHub.com. So a valid GitHub.com token must be passed to the workflow in that case. If that is not set the default ${{ github.token }} should be used instead.

As long as that parameter is optional and defaults to ${{ github.token }} it will not break anything when running on GitHub.com, but will allow GHES users to provide a token valid on GitHub.com.

Typically adding this to action.yml will do the trick:

inputs:
  githubcom-token:
    description: >
     Access token for reading from GitHub.com when the action is running on GitHub Enterprise Server (GHES).
     https://github.com/actions/create-github-app-token can be used to obtain such a token. The token only need to 
     be scoped with read access to public repositories.
    default: ${{ github.token }}

Then pass that input to actions/checkout.

The aquasecurity/trivy-action would also need to be updated with the same input and pass that to setup-trivy.

A user of GHES can then utilize https://github.com/actions/create-github-app-token to create a token for GitHub.com and pass that to aquasecurity/trivy-action and it will flow down to the checkout action.

We probably don't need to add input for github-server-url, since in all cases action/checkout in setup-trivy should connect to the github.com server. we will explicitly indicate this server and that will be enough

That's true. Using https://github.com should be sufficient as that's where the trivy org is located.

[DmitriyLewen]

@palloberg thanks for this information!
Can you test setup-trivy from #12?

[palloberg]

Tested the trivy-action@master now with the new token-setup-trivy parameter it it works like a charm. Thank you!

[fletch3555]

Alternatively fetching the install.sh from https://raw.githubusercontent.com/aquasecurity/trivy/refs/heads/main/contrib/install.sh (or https://raw.githubusercontent.com/aquasecurity/trivy/refs/tags/SOMETAG/contrib/install.sh when another version than latest is requested) would bypass the whole authentication problem.

@DmitriyLewen,

If I may, I'd like to bring attention back to this comment. The checkout step is currently the only thing (that I could find) that requires a token, and it's only checking out a single file. Could we not just directly reference that shell script and avoid this entirely?

I ask because my organization strongly discourages any use of github.com in favor of our own GHES instance, and therefore we don't have a good way to acquire a PAT needed for pulling from github.com.

[DmitriyLewen]

Hello @fletch3555

Unfortunately, there is no universal way to solve the problems for all users.

We used this way in trivy-action:
https://github.com/aquasecurity/trivy-action/blob/a20de5420d57c4102486cdd9578b45609c99d7eb/action.yaml#L110-L112

But users started reporting that their runners do not have curl, sudo, wget, etc. (see aquasecurity/trivy-action#403).
That's why we abandoned this way.

[fletch3555]

@DmitriyLewen could it be done like other setup jobs then? For example, actions/setup-python does it as a nodejs action rather than a composite action. It fetches/runs a setup.sh script just like you are here but via nodejs code and therefore not requiring curl/wget/etc, and also not requiring sudo (though that's more about what's in the script, and I haven't looked at that closely).

Alternatively, this used to be a docker-based action several versions ago. Switching back to that would also solve this as you would have full control over the environment. Though, I'm sure there was some reason for switching away from it.

ETA - The only reason sudo is needed is because you're forcing it to install to a privileged directory (/usr/local/bin). Letting that install to the default path ./bin (or perhaps changing to something like ~/bin) and removing sudo works fine. You may just need to add that path to $PATH as well. For a GHA install which should be treated as ephemeral, that should be a rather easy solution to the sudo problem. It doesn't solve the curl/wget problem, though the suggestion above likely would, and even better, it uses the built-in tool-cache package, allowing for caching of download

[DmitriyLewen]

Alternatively, this used to be a docker-based action several versions ago.

We can't use docker-based action, because we can't add cache logic for it (that is why we updated trivy-action)

actions/setup-python does it as a nodejs action rather than a composite action.

I created #15. But I don't have time to work on it now. If you have time - you can create a PR and we will consider it.