fix: ensure no self-hosted runners for generic generators

[ramonpetgrave64]

Update

We're putting this PR on hold until we can get an answer in

• https://github.com/orgs/community/discussions/111347

Summary

Fixes #1868

Fails the generator workflows when they detect that other jobs in the calling workflow are targeting self-hosted runners.

A new function first fetches a list of all jobs in the calling workflow, examines their specified target runs-on labels, and then compares against any known self-hosted runners' labels.

We do this extra comparison because a user need not specify the target runs-on label "self-hosted" in order to actually run on their self-hosted runners: If they have a runner with a custom labels "cloudtop" or even "ubuntu-latest", they need only specify runs-on: "cloudtop" or rune-on: "ubuntu-latest" to make their job run on their self-hosted runner.

Caveats

Personal Access Token

The call to check the list of self-hosted runners requires a Personal Access Token with administration:read permissions. This is a breaking change, and will also require updates to many of our e2e tests bth in this repo and example-package.

Defeatable

A repo owner with bad intentions could still get past this check: after the actual artifact build and before our checks, they can edit the properties of their self-hosted runner to remove the label in question.

Testing Process

• Added unit tests for a new ensureOnlyGithubHostedRunners() in detect.ts.
• Added more unit tests to main.ts, wich calls ensureOnlyGithubHostedRunners()
• Added another workflow pre-submit.actions-for-pr.yml that does a checkout on the PR's copy of of the code before doing a test on each of the github actions.

• [ ] TODO: add e2e tests to slsa-framework/example-package
• OR
• [ ] TODO: add a pre-submit test to this workflow that attempts to run a job on a self-hosted runner (after we make one) and checks the (needs.detect-env.outputs.outcome).

Forked slsa-github-generator and ran the generator within my won custom workflow that specifies various combinations of self-hosted anad non self-hosted runner labels.

• https://github.com/ramonpetgrave64/my-example-gradle-project/actions/runs/8085634419/job/22093629374?pr=2

Checklist

• [x] Review the contributing guidelines
• [x] Add a reference to related issues in the PR description.
• [x] Update documentation if applicable.
• [x] Add unit tests if applicable.
• [x] Add changes to the CHANGELOG if applicable.

[ramonpetgrave64]

I think I'm currently having an issue in CI because I'm using the token as a secret, and because my PR is coming from a fork. https://github.com/actions/toolkit/issues/465#issuecomment-630227277

Failed to retrieve OIDC token. This may be due to missing id-token: write permissions.
Error: Parameter token or opts.auth is required
Error: No repository detected.

I may be able to workaorund this with

with:
  token: ${{ secrets.token || github.token }}

UPDATE: that fixed the problem.

[laurentsimon]

We do this extra comparison because a user need not specify the target runs-on label "self-hosted" in order to actually run on their self-hosted runners: If they have a runner with a custom labels "cloudtop" or even "ubuntu-latest", they need only specify runs-on: "cloudtop" or rune-on: "ubuntu-latest" to make their job run on their self-hosted runner.

Does this contradict https://github.com/slsa-framework/slsa-github-generator/issues/1868#issuecomment-1966251208? Shall we create an issue on https://github.com/actions/runner to ask to update the doc?

[ramonpetgrave64]

LGTM overall. Can we create a dedicated action for the detection of self-hosted runners? It will make the code more re-usable when we need it.

I think you're right. And it should be easier to write a e2e test for that way

[laurentsimon]

We do this extra comparison because a user need not specify the target runs-on label "self-hosted" in order to actually run on their self-hosted runners: If they have a runner with a custom labels "cloudtop" or even "ubuntu-latest", they need only specify runs-on: "cloudtop" or rune-on: "ubuntu-latest" to make their job run on their self-hosted runner.

Does this contradict #1868 (comment)? Shall we create an issue on https://github.com/actions/runner to ask to update the doc?

Please cc me on the issue you create on their repo

[ramonpetgrave64]

LGTM overall. Can we create a dedicated action for the detection of self-hosted runners? It will make the code more re-usable when we need it.

I think you're right. And it should be easier to write a e2e test for that way

I've added it as a separate action. Still w work-in-progress, however, until we can get a good e2e story.