Permissions nesecary to comment on a PR #26644

WyriHaximus · 2021-05-09T17:07:55Z

WyriHaximus
May 9, 2021

Been working on a workflow that will comment based on changes in the PR. But when the PR comes from the outside or Dependabot it doesn’t have all the write permissions the repo’s owner has. Does anyone know which permissions have to be set to what to make an action be allowed to comment on a PR, when that PR isn’t coming from the repo owner?

Answered by WyriHaximus

May 16, 2021

So I currently came to this after a Twitter thread with one of the Dependabot people:

name: Composer Diff
on:
  pull_request_target:
    types:
      - opened
      - synchronize
      - reopened
permissions:
  pull-requests: write
jobs:
  comment-composer-lock-diff:
    name: Comment composer.lock diff
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Comment composer.lock diff
        uses: WyriHaximus/github-action-composer.lock-diff@main
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

For reference that Twitter thread can be found here: https://twitter.com/WyriHaximus/status/1393679576828686340

View full answer

jsoref · 2021-05-10T01:32:08Z

jsoref
May 10, 2021

Dependabot is fun.

Technically according to the documentation:

docs.github.com

Commenting on an issue when a label is added - GitHub Docs

//docs.github.com/en/actions/guides/commenting-on-an-issue-when-a-label-is-added

All you need is:

    permissions:
      issues: write

Practically, you need a PAT

docs.github.com

Creating a personal access token - GitHub Docs

//docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token

And practically, the scopes don’t align well with comment:

docs.github.com

Scopes for OAuth Apps - GitHub Docs

//docs.github.com/en/developers/apps/scopes-for-oauth-apps

What I’ve managed to do in general is rely on pull_request_target
But do read

securitylab.github.com

Keeping your GitHub Actions and workflows secure: Preventing pwn requests

In this article, we’ll discuss some common security malpractices for GitHub Actions and workflows, and how to best avoid them. Our examples are based on real-world GitHub workflow implementation vulnerabilities the GitHub Security Lab has reported to...

Because if you mess up, the consequences are pretty grave.

It’d be really nice if there was a comment scope available. Because a huge portion of GitHub actins really only need this permission. But, sadly, it doesn’t appear to exist today.

1 reply

RAmi767mlk Sep 20, 2022

طيب انا ما عندي فلوس عشان

WyriHaximus · 2021-05-10T17:54:32Z

WyriHaximus
May 10, 2021
Author

Thanks! Been really hoping to avoid using a PAT because that widens the attack possibilities with it significantly rather than reducing it. And just setting the issues to write permissions works fine when I make the PR. But any external party still gets blocked, currently attempting the route as described here: "Error: Resource not accessible by integration" when using Dependabot · Issue #298 · marocchino/sticky-pull-request-comment · GitHub

Still feels as way to much work for something that should be handled more securely by the platform. Right now having to jump through hoops makes it to easy to implement something insecurely.

0 replies

jsoref · 2021-05-10T18:48:44Z

jsoref
May 10, 2021

Yeah, I’m currently playing with variations.

I’m still working on getting all of my pieces to support outputs so that I could talk to that action.

I agree, it’s incredibly inelegant.

Although, one complaint people have about my thing is that it leaves too many comments, whereas a single running comment would be nice, so it’s possible that I’ll want to use that action (I’ve been thinking about it for the past week or two).

1 reply

jsoref Sep 20, 2022

I should note that I now have my action automatically collapsing previous comments.

https://github.com/check-spelling/check-spelling/blob/0dfb89018e1aa8e18e3e108c294d34870161a316/unknown-words.sh

WyriHaximus · 2021-05-16T10:39:04Z

WyriHaximus
May 16, 2021
Author

So I currently came to this after a Twitter thread with one of the Dependabot people:

name: Composer Diff
on:
  pull_request_target:
    types:
      - opened
      - synchronize
      - reopened
permissions:
  pull-requests: write
jobs:
  comment-composer-lock-diff:
    name: Comment composer.lock diff
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Comment composer.lock diff
        uses: WyriHaximus/github-action-composer.lock-diff@main
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

For reference that Twitter thread can be found here: https://twitter.com/WyriHaximus/status/1393679576828686340

0 replies

jsoref · 2021-06-13T14:30:11Z

jsoref
Jun 13, 2021

Btw, I’m shocked to see anyone using actions/checkout@v1 at this point.

  <a href="/actions/checkout/tree/releases/v1" target="_blank" rel="noopener nofollow ugc">github.com</a>

actions/checkout

releases/v1

Action for checking out a repo. Contribute to actions/checkout development by creating an account on GitHub.

v1 has been dead since:

  <a href="/actions/checkout/commit/0b496e91ec7ae4428c3ed2eeb4c3a40df431f2cc" target="_blank" rel="noopener nofollow ugc">github.com/actions/checkout</a>

Upgrade checkout to v1.1.0 to better support scripting git. (#56)

<div class="github-info">
  <div class="date">
    committed <span class="discourse-local-date" data-format="ll" data-date="2019-10-25" data-time="14:52:59" data-timezone="UTC">02:52PM - 25 Oct 19 UTC</span>
  </div>

  <div class="user">
    <a href="/TingluoHuang" target="_blank" rel="noopener nofollow ugc">
      <img alt="TingluoHuang" src="https://user-images.githubusercontent.com/2119212/181099034-45ce1c49-c41a-43c6-998b-0f75fcad50fb.png" class="onebox-avatar-inline" width="20" height="20">
      TingluoHuang
    </a>
  </div>

  <div class="lines" title="changed 3 files with 54 additions and 7 deletions">
    <a href="/actions/checkout/commit/0b496e91ec7ae4428c3ed2eeb4c3a40df431f2cc" target="_blank" rel="noopener nofollow ugc">
      <span class="added">+54</span>
      <span class="removed">-7</span>
    </a>
  </div>
</div>

* Upgrade checkout to v1.1.0 to better support scripting git.

add changelog…
Update README.md
Add local testing yaml
Add Status Badge to readme

0 replies

WyriHaximus · 2021-06-13T16:30:36Z

WyriHaximus
Jun 13, 2021
Author

Why? That commit is included in the v1 tag, I’m rather shocked that you didn’t notice that as it’s right there when you open the page:

image811×418 22 KB

0 replies

jsoref · 2021-06-13T17:35:15Z

jsoref
Jun 13, 2021

Because v2 was a major change from v1; v1 is clearly not getting updates. So, unless there’s a specific reason to use v1, one really shouldn’t.

  <a href="/actions/checkout/releases/tag/v2.0.0" target="_blank" rel="noopener nofollow ugc">GitHub</a>

Release v2.0.0 · actions/checkout

Improved fetch performance

The default behavior now fetches only the commit being checked-out

Script authenticated git commands

Persists the input token in the local git config
Enables your scr...

0 replies

WyriHaximus · 2021-06-13T18:03:04Z

WyriHaximus
Jun 13, 2021
Author

Ow absolutely, most of my workflows (that I haven’t forgotten to update) are running on v2, especially ones with big repositories. However, that specific action I’ve build has a very specific git use case that I’ve been unable to get working on v2, so yeah it uses v1 because that just works.

0 replies

jsoref · 2022-05-19T16:05:22Z

jsoref
May 19, 2022

I should note that while commenting requires permissions, if all you want is to provide a report, there’s a new feature called a job summary:

  <a href="https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/" target="_blank" rel="noopener" title="04:00PM - 09 May 2022">The GitHub Blog – 9 May 22</a>

Supercharging GitHub Actions with Job Summaries | The GitHub Blog

You can now output and group custom Markdown content on the Actions run summary page.

Est. reading time: 3 minutes

… and it doesn’t require additional permissions.

0 replies

WyriHaximus · 2022-05-20T18:20:29Z

WyriHaximus
May 20, 2022
Author

Does it support updating the same summary if you push again to the same PR?

0 replies

jsoref · 2022-05-20T19:24:19Z

jsoref
May 20, 2022

Summaries are assigned to jobs, so each job gets its own summary.

Roughly it ends up being a non-issue.

Note: I haven’t deployed this feature (for various reasons). I might be able to in June or July.

0 replies

WyriHaximus · 2022-05-21T07:45:57Z

WyriHaximus
May 21, 2022
Author

Also still need to check it out, but if only the latest summary is shown on the PR page it could work. Will see if I can have a try at this soon

0 replies

jsoref · 2022-05-22T16:30:54Z

jsoref
May 22, 2022

I believe they’re basically only reachable via the ✅/❌ for the commit or the summary box at the bottom of the PR.

0 replies

sbernard31 · 2022-09-20T13:48:22Z

sbernard31
Sep 20, 2022

@WyriHaximus do you have any feedback about this ? (usage of summary OR good way to put comment on PR with github action from forked repo)

I looked at https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ and I ask my self if there is a better way than pull_request + artifact + workflow_run. I feel this is a lot of overhead and would be happy to find something lighter.

Edit:

I just see that you propose pull_request_target with limited pull_request:write permissions but I don't know if in your case it's OK but in my case, I feel an attacker could steal this token to do some mess on all PRs of my repository. Not sure they could do something very annoying with this access right.

6 replies

jsoref Sep 20, 2022

Stolen tokens are definitely a huge risk, and my initial efforts at workflows indeed were at risk.

I believe my current workflow isn't. But, I could be wrong.

I'd definitely prefer to have a specific permission for comments as opposed to having to rely on pull-requests: write or contents: write. It seems to my naive perspective like a totally reasonable ask.

sbernard31 Sep 21, 2022

the best way forward would be that GitHub provides an "action only permission" where you only can create and update or delete your own comments.

Clearly that sounds a really good idea.
Any way to ping a github dev to share this idea ?

jsoref Sep 21, 2022

I haven't found an effective channel to do so.

sbernard31 Sep 21, 2022

Reading this, It seems the best way should be to create a discussion and get lot of upvote.

Guys, do you think we should create a new discussion mainly focus on this idea :

GitHub provides an "action only permission" where you only can create and update or delete your own comments.

The idea will be to expose the needs,
then why current solution is not so good,
and finally propose this idea ☝️
(of course I put a link to this discussion too)

(I can do that if needed)

Or we should just use this issue and upvote it ?

jsoref Sep 21, 2022

@WyriHaximus: can you fix the spelling of this one to say necessary instead of nesecary?

I have no sense of the best way to organize, sorry.

Permissions nesecary to comment on a PR #26644

Uh oh!

Replies: 14 comments · 8 replies

Uh oh!

Uh oh!

Uh oh!

WyriHaximus May 10, 2021 Author

Uh oh!

Uh oh!

Uh oh!

WyriHaximus May 16, 2021 Author

Uh oh!

Uh oh!

WyriHaximus Jun 13, 2021 Author

Uh oh!

Uh oh!

WyriHaximus Jun 13, 2021 Author

Uh oh!

Uh oh!

WyriHaximus May 20, 2022 Author

Uh oh!

Uh oh!

WyriHaximus May 21, 2022 Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Replies: 14 comments 8 replies

WyriHaximus
May 10, 2021
Author

WyriHaximus
May 16, 2021
Author

WyriHaximus
Jun 13, 2021
Author

WyriHaximus
Jun 13, 2021
Author

WyriHaximus
May 20, 2022
Author

WyriHaximus
May 21, 2022
Author