If I'm an external contributor, no PR comment is created (403 error)

[davidkopp]

Description

The GitHub Action fails to create PR comments with the measurement results due to a 403 permission error when triggered by external pull requests (from forks). If understand it correctly, it works fine for repository admins/collaborators but fails for external contributors due to restricted github.token permissions on fork-based PRs.

Error

{
 "message": "Resource not accessible by integration",
 "documentation_url": "https://docs.github.com/rest/issues/comments#create-an-issue-comment",
 "status": "403"
}

Example run: https://github.com/green-coding-solutions/green-metrics-tool/actions/runs/15945237760/job/44978437919

Possible Solution

Add explicit permissions to the workflow to handle external pull requests:

permissions:
  pull-requests: write

Docs: https://docs.github.com/en/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token

[ArneTR]

Hmm, interesting. Not seen that so far.

The solution you propose seems not to be the solver as this is how the Worklflow is already configured: https://github.com/green-coding-solutions/green-metrics-tool/blob/981e646b5753fd22144b92445571b3ca762f6bc2/.github/workflows/tests-vm-pr.yml#L10

Currently I do not have any idea here. Will look at it next week. Thanks for raising the issue!

[davidkopp]

The GitHub Actions Docs states that the "Maximum access for pull requests from public forked repositories" is read.

A proposed solution is to use the pull_request_target event instead of pull_request. The pull_request_target event runs in the context of the target of the pull request, rather than in the context of the merge commit, as the pull_request event does (source).

This event allows your workflow to do things like label or comment on pull requests from forks.

However, there are security concerns using the pull_request_target event:

For workflows that are triggered by the pull_request_target event, the GITHUB_TOKEN is granted read/write repository permission unless the permissions key is specified and the workflow can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch. To help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered. For more information, see Keeping your GitHub Actions and workflows secure: Preventing pwn requests on the GitHub Security Lab website.

As Eco CI is usually used in CI pipelines where builds are done, I guess it would be problematic to propose using the pull_request_target event.

A better solution seems to be splitting the pipeline into two parts: one with the safe pull_request event (like it is at the moment) and one using workflow_run that is only responsible for creating the PR comment. See the file CommentPR.yml here as an example: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/

[ArneTR]

we had pull_request_target for a while but ran into issues as pipelines ran without oversight and even malicious code could be run. So that is sadly not an option, as you already outline.

The option of having a separate pipeline I do not really see as users than have to create multiple workflow files and/or multiple jobs. The complaints are already that integration Eco CI involves quite some boilerplate text in the .yml files.

I do not really have an idea on how to proceed here tbh ... leaving this open. Might be moved to a discussion if no further input happens

[ArneTR]

@ribalba do you have an idea how to solve this? you were looking into the pull_request_target and requesting verification for every run at the time (which we could not get working)

[ribalba]

So I looked into this and I don't think it is possible without "compromising" the keys. I got something working with "allowing" a run by one of the maintainers but then every run needs to be triggered. There is no way of only having this for external runs.