fix(ci): record and use the PR number to post the comment

[upils]

• Have you signed the CLA?

---

Properly get the PR number associated to the benchmark run to post the comment
in the right place.
The approach tries to limit injection risk, applying the strategy recommended in
https://securitylab.github.com/resources/github-actions-untrusted-input

Tested with upils#12 after merging this change in my fork.

[polarathene]

At a glance I think these changes would introduce an exploit to enable an attacker access to a trusted workflow environment with access to secrets?

I've linked an alternative approach that demonstrates how to get a PR number more safely.

[polarathene]

Short version:

• ⚠️ Careful with expression use for action inputs like run. The contents is interpolated by GHA before processed by the action (in this case shell script execution). An attacker can manipulate their branch name to compromise this workflow and gain access to secrets.
• I've provided two suggested revisions with notes, but the gh pr list (GraphQL) suggestion is more strict on searching for the intended PR and should be less at risk to trigger secondary rate limits (but for this repo I don't think you have the activity for that to be a real concern).

[polarathene]

Just for context of this removal for anyone interested, github.event.workflow_run.pull_requests is only present when the PR is not a branch from a fork of the repo IIRC, so it's an unreliable source.

[niemeyer]

I'm missing something the context for this PR... how come we have the PR at hand and not the number?

This whole workflow is conditioning on github.event.workflow_run.event == 'pull_request'.

I realize that this is all being done in the name of security, but the amout of fiddling with stuff that supposedly should be simple really makes it feel like we'll see more serious issues soon.

[upils]

I'm missing something the context for this PR... how come we have the PR at hand and not the number?

This workflow is triggered by the other one and is receiving a github.event.workflow_run payload. However github.event.workflow_run.pull_requests is empty when triggered from a fork. This issue was raised to GitHub multiple times, but AFAIK they never really answered nor addressed it. So we have to work around that and resort to a more convoluted method to get the PR number.

[letFunny]

A couple of questions only. Sad state of affairs for Github, honestly. Thanks for the work here!

[letFunny]

Thanks for working on this Paul, we discussed offline and this looks like one of the safest and simplest approaches. It is a bit sad that:

1. There is not a good way in Github to do something as trivial as posting a comment securely.
2. There is no standardized action in Canonical that has been vetted by security.

For now, let's move forward with this.

[niemeyer]

I'm missing something the context for this PR... how come we have the PR at hand and not the number?

This whole workflow is conditioning on github.event.workflow_run.event == 'pull_request'.

I realize that this is all being done in the name of security, but the amout of fiddling with stuff that supposedly should be simple really makes it feel like we'll see more serious issues soon.

[polarathene]

@niemeyer If you are aware of a better way to approach this, let me know. Review already addressed two concerns where the contributor could have gained access to secrets 😓

If you would like to simplify it in this case you could just upload the PR number from pull_request to the workflow_run add that to the GITHUB_OUTPUT, but be mindful if anyone were to maintain the workflow or another like it and introduce another output, the PR author would be able to manipulate that.

Below is just extra context on the security decisions if it's helpful.

---

+ uses: mshick/add-pr-comment@dd126dd8c253650d181ad9538d8b4fa218fc31e8 # v2
  with:
-   message-path: benchmark-report.txt
-   issue: ${{ github.event.workflow_run.pull_requests[0].number }}

I'm missing something the context for this PR... how come we have the PR at hand and not the number?

As mentioned in earlier review comment (which yours appears associated to but Github shows it disjoint on my end at least), the information is not available from PRs coming from other forks.

I realize that this is all being done in the name of security, but the amout of fiddling with stuff that supposedly should be simple really makes it feel like we'll see more serious issues soon.

It's an unfortunate issue with public CI running with third-party contributions that can add untrusted code (a contributor can modify the pull_request event workflow trigger in their own PR and Github Actions will run that modification).

Thus if you need access to secrets, you must do this fiddling to volley over into a trusted workflow.

For a common scenario like needing a PR number as you switch between the untrusted pull_request context to a trusted context in a separate workflow, this is indeed frustrating and has security risks as discussed in this PR that can be easy to make. Until Github resolves it, you either do it this way or adopt an alternative CI.

If you'd like me to direct you to advice from the Github Security Labs team, let me know.

---

It's possible to do an alternative with the pull_request_target event, which will not run any modified version on the PR branch, but will run with access to secrets.

pull_request_target is strongly discouraged however, since you are running the workflow on PR content with access to secrets if you are likewise not careful, that can be exploited (recently this happened to the trivy project (a popular security scanner) IIRC that used pull_request_target, and as a result their github action was compromised that all projects that ran that newer version would likewise be compromised by running malware in the downstream projects trusted workflows using that action 😓).

The approach taken in this PR here is much safer as only the PR number is needed to add a comment (paired with a markdown document that the PR author could manipulate the file content of). pull_request_target can have other risks like cache poisoning IIRC.

The approach taken here is more important if you did have execution of untrusted code occurring (which you'd handle that in the pull_request workflow), and the workflow_run workflow would strictly not run any untrusted code.