Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable when PR from a fork to upstream

[hk21702]

The ACTIONS_ID_TOKEN_REQUEST_URL env variable appears to be unavailable if this action is run on a pull request from a fork into an upstream branch.

It works perfectly fine when ran in the fork itself, or if the pull request is from a branch belonging to the upstream repository itself. It could be my mistake with configuration, or just a misunderstanding of how the action is supposed to work on my part. It'd be great if a fix could be provided for this, or at least a workaround where for this specific situation the step is skipped.

Here is an example of a run with the situation I'm describing: https://github.com/RimSort/RimSort/actions/runs/9338649185

[phillmv]

Hi, and thanks for trying out our feature.

What a puzzling error! Glancing over your workflows, it sure looks like you're doing everything right.

That said… this error smells like a permissions issue, and once I read "from a fork" my spidey sense started tingling; for security & abuse prevention reasons, workflows in forks have all sorts of not-necessarily-intuitive behaviour.

I looked this up in our public docs and found the following link: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs#changing-the-permissions-in-a-forked-repository

You can use the permissions key to add and remove read permissions for forked repositories, but typically you can't grant write access.

Which would explain why the workflow is not fetching the id-token. Is it possible that this setting is not enabled?

Caveat emptor: I suggest thinking carefully about what you might be enabling if you turn this feature on, i.e. you might inadvertently allow project outsiders to push packages / you might want to consider how to adequately scope permissions or workflow triggers (which I see some evidence of in the build file). I myself am not an expert on how to structure this properly, and am just raising the possibility.

[hk21702]

Thanks for the suggestion! It does seem like a permission issue. I think a potentially safe way of doing this would be to just disable the attestation step for this specific case? Or at least let it safely fail only in this specific case. I'm not sure how to do this such that it safely fails in the use case of a PR into upstream from a fork but not within a fork itself.

[phillmv]

I think a potentially safe way of doing this would be to just disable the attestation step for this specific case?

Without looking into your project specifically, my recommendation is as follows:

1. you want to attest any built artifacts that are distributed to end-users
2. often we build artifacts as part of the pull request process
3. but this model is kinda awkward in the context of open pull requests, SO:

• What if you move the build artifact step to a workflow that is fired after merges are made to your main branch? That way you step over any permissions issues since it only fires in the context of your repo, not in the fork, and after a project maintainer has blessed it.

(if you're building artifacts in a pull request where the tokens don't have write access this might be wasted effort/compute anyways 🤔, cos the artifacts will by definition be thrown away)

[jsoref]

Consumers that want to use this would need to use pull_request_target instead of pull_request.

But before you do, you need to read at least:

• Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests
• Keeping your GitHub Actions and workflows secure Part 2: Untrusted input
  
• Keeping your GitHub Actions and workflows secure Part 3: How to trust your building blocks
• Keeping your GitHub Actions and workflows secure Part 4: New vulnerability patterns and mitigation strategies

Roughly, it's possible to do what you want with:

on:
  pull_request_target:
    # When run for this event, the workflow will run based on the destination repository's copy of the workflow,
    # not the attacker's copy of the workflow.
    # Checkouts of the attacker's attacking content should only be done in the `untrustworthy` job.
    # No code should be seen as trustworthy in that job, because it's attacker controlled.
    # The `very-dangerous` job should only run code from the default checkout (and only if necessary,
    # preferably it should be able to skip any checkout and skip all `run:` and just use `uses:` steps).

jobs:
  untrustworthy:
    permissions:
      contents: read
    steps:
    - uses: actions/checkout@v4
      with:
        ref: ${{ github.event.pull_request.head.sha }} # From here on in this job, no program or file being used is trustworthy, whatever it is, it's attacker controlled.
    - name: build
      run: |
        # you should do your building here...
    - uses: actions/upload-artifact@v4
      with:
        name: untrustworthy
        retention-days: 1
        path: build/
  very-dangerous:
    permissions:
      id-token: write
      attestations: write
      packages: write
      # contents: read
    needs:
    - untrustworthy
    steps:
    - uses: actions/checkout@v4
      if: false # ideally you do not use `runs:` and do not need a checkout but are instead only using `uses:` statements that do not _run_ any programs from your `${{ github.workspace }}` because that content (well at least `${{ github.workspace }}/untrustworthy`) is attacker controlled.
      # This checkout is optional, ideally you do not check out *anything* and do not *run* anything, but if you do need to *run* _anything_, it should be from this checkout and not the `untrustworthy
    - uses: actions/download-artifact@v4
      with:
        name: untrustworthy
        path: untrustworthy
    - uses: actions/attest-build-provenance@v1
      with:
        path: untrustworthy/build/
    - uses: actions/upload-artifact@v4
      with:
        name: attested-untrustworthy
        path: untrustworthy/build/

Warning

Doing anything like this is potentially very dangerous, hence you really need to understand what you're doing and the risks. But, you really want to have two jobs:

• one for untrustworthy where the attacker is understood to control everything, but which produces output artifacts to share to very-dangerous.
• one for very-dangerous where it's your job to very carefully handle the attacker controlled outputs from untrustworthy.