starter-workflow template gives `Resource not accessible by integration`

[msamprz]

Hi there,

I've implemented the exact Labeler workflow as the starter-workflow template in the dir path .github/workflows/label.yml.

I have also added the .github/labeler.yml file with the configuration below:

Trader: packages/trader/**/*

Bot: packages/bot/**/*

Core: packages/core/**/*

Components: packages/components/**/*

Shared: packages/shared/**/*

The action is recognised and runs on PR, however the Labeler action resolves with the following error:

##[error]HttpError: Resource not accessible by integration
##[error]Resource not accessible by integration
##[error]Node run failed with exit code 1

Googling seems to relate that error with invalid access to the repo by the action app, so I thought I'd create an issue and disable the action for now, but would be happy to know if there's something I have missed out that will be able to solve this issue for me.

Thanks.

[ibakshay]

You can see from this issue only on how many users are affected because of this limitation from GitHub Actions 😞.

[Ecco]

Could someone please reopen this? I know the "bug" doesn't come from actions/labeler itself, but this is such a major limitation that someone at GitHub should find a way to make this work!!

Seriously, having running actions from forks in a read-only environment makes actions pretty much useless! You can't run any kind of CI / lint / action really. Well, you can, but you cannot report it within the PR itself, which makes the entire thing pointless!

[potiuk]

I am afraid, this is as it should be. I hit the problem myself recently - but I had to find another solution to caching problems in this case. I did not realise at first but when I imagined what "roque users" could do with write access - without code review from committers to our code - it was scary! Replacing pushed images with some "roque ones", pushing code and tags .. you name it.

I think it's a good rule and one that makes you think and try other solutions as you might simply not realise how dangerous it is.

[Ecco]

I'll have to respectfully disagree. PRs should at the very least be able to act on themselves…

[Ecco]

I went on a (long) rant on GitHub Community about this too

[potiuk]

@Ecco > what do you mean by "Act on themselves" ? As described here: https://help.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token#permissions-for-the-github_token - the actions are per service not per PR. How would you act "on themselves" for:

1) actions, 2) checks, 3) contents 4) deployments 5) issues 6) metadata, 7) packages 9) repository projects, 10) statuses. ....

There is one case 8) pull request - that falls into "act on themselves" case but what exactly do you want for the token to allow on the pull request?

[Ecco]

@potiuk I suggest you read the comment I wrote on GitHub Community, it explains it all 😄

[joshgoebel]

GitHub actions if they are not incredibly broken (seems perhaps they are working as designed) then they are at the very least marketed and misrepresented horribly by GitHub. I wish I had back the hour or two I wasted trying to do anything useful with Actions on a OSS project. I'm sure they are working for someone, but I wish GitHub would write better docs and market them in a more responsible fashion.

It seems GitHub knows enough about a project (based on all the other info it provides the admin) that it could make better choices about suggesting someone use these tools if there was zero chance they were going to fit the workflow in question. @Ecco I feel your pain.

[Ecco]

@yyyc514 Would you mind upvoting my comment on GitHub community to try and raise awareness about this? Thanks 😄

[joshgoebel]

I'm not sure we're saying exactly the same thing. I don't want to be too explicit about what the problem is here exactly - or how it needs to be fixed, but there is a big problem with Actions (for many people).

[potiuk]

@Ecco I did. Comment and label. It is what I saw there.

Suggestion: Maybe you can you simply open an issue when you explicitly say "I want my Github Action can comment on the PR from the forked repo" and another " I want my Github Action can label the PR from a forked repo"?

I think such requests should be treated individually. Each of them has a different security considerations and they can have some profound impact. And maybe there is a reason for doing it this way. For example comment on a PR might in-turn trigger another action.

I've been following (actually I neede it for Apache Airfow that I am PMC member of) a similar discussion in GitLab: https://gitlab.com/gitlab-org/gitlab/issues/5667#note_223311926 and I followed all the discussions, related issues and there are many, many security considerations that you have to take into account. Switching to read-only is really reasonable before you understand and discuss all the consequences of "write" access for forked repos for any of the "actions" you can have "write" access to.

Long story short - implementing fork support for GitLab has been continuously postponed for last 6-7 months or so. And I start to believe it makes sense as those potential security problems can be really bad. I suggest @ecco -> read discussions there. They are very insightful.

[fishcharlie]

Is there any workaround to this in the meantime? I tried to implement a solution like https://github.com/ethereum/ethereum-org-website/pull/345 but it still seems to be failing on forked repos.

https://github.com/dynamoose/dynamoose/pull/906/commits/5cf55f24e2e00dea6c6127abc278f944b028862a

[samajammin]

I still haven't found a solution here.

I tried adding this as a periodic cron job but hit this error: https://github.com/actions/labeler/blob/4b52aec09ba832eb9aecccddbccce644ba9ba69d/src/main.ts#L20

As @damccorm mentioned, the action assumes it's going to be run on a PR & fails when it's unable to access github.context.payload.pull_request within getPrNumber().

[jpmcb]

I've created a github actions workflow that will automatically label PRs from the default branch of a repo based on a cron schedule. This way, PRs from forks will be labeled appropriately - https://github.com/marketplace/actions/prow-github-actions

Here's a working example: https://github.com/jpmcb/prow-github-actions/pull/12

prow-github-actions has alot of other features too, so feel free to raise an issue with questions, bugs, or feature requests!

[iranzo]

This issue appears as closed but the error still happens, any hint?

[anuraghazra]

So there is no solution? this issue made this action totally unusable. :(

[iranzo]

I' m using the cron approach and works fine.

Sent from mobile

El sáb., 8 ago. 2020 19:43, Anurag Hazra notifications@github.com escribió:

So there is no solution? this issue made this action totally unusable. :(

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/actions/labeler/issues/12#issuecomment-670955004, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACMJDZOYAPLIYKUURHCQZDR7WFD3ANCNFSM4IPNCSLQ .

[ylemkimon]

tl;dr, change

on:
- pull_request

to

on:
- pull_request_target

---

GitHub has introduced a new event type: pull_request_target, which allows to run workflows from base branch and pass a token with write permission.

In order to solve this, we’ve added a new pull_request_target event, which behaves in an almost identical way to the pull_request event with the same set of filters and payload. However, instead of running against the workflow and code from the merge commit, the event runs against the workflow and code from the base of the pull request. This means the workflow is running from a trusted source and is given access to a read/write token as well as secrets enabling the maintainer to safely comment on or label a pull request. This event can be used in combination with the private repository settings as well.

[ebwinters]

Adding the - pull_request_target is not enough. You need to go to the org/enterprise settings and do the following

[frankenstein91]

it failed on me too... Do you know how to fix it? https://github.com/frankenstein91/Arch-Ansible-Install/pull/6

[TurnrDev]

So it turns out that this is working as intended after all. We can't give write permissions to forks for security reasons (e.g. the forked user changes your yaml file to write bad things to your repo), so this should fail on forks.

With that said, the docs are wrong here and need to be updated. Already added actions/starter-workflows#78 to update the template, will also follow up to update docs here.

I'm having this issue after transferring a repository to an organisation, no forks

[OndroMih]

It looks like a solution is to trigger the action on the pull_request_target event instead of the pull-request event.

I see that the README is now updated to use the pull_request_target event. I just wanted to comment about it also here because Github's template still uses pull_request and it might be useful to people that search for a solution and they come across this page.

[TobKed]

@OndroMih

It looks like a solution is to trigger the action on the pull_request_target event instead of the pull-request event.

This may be unsecure, PTAL at Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests

TL;DR: Combining pull_request_target workflow trigger with an explicit checkout of an untrusted PR is a dangerous practice that may lead to repository compromise.

It was solved in another, more secure way (different action used, bur rule is the same) in https://github.com/apache/incubator-doris/ and https://github.com/apache/airflow. PTAL on usage:

• https://github.com/apache/incubator-doris/blob/c2520c878c3d827e27c32f1dab5e5953a25b52e7/.github/workflows/approve-label-trigger.yml
• https://github.com/apache/incubator-doris/blob/c2520c878c3d827e27c32f1dab5e5953a25b52e7/.github/workflows/approve-label.yml

[igor-petrik-invitae]

I'm experiencing this in an enterprise repo with PRs opened by dependabot. As far as I can tell, dependabot creates a branch, not a fork. Is there a proper/secure way to get this action to work for dependabot PRs?

[dgokcin]

I am also having the same issue on the PRs opened by dependabot. The problematic action is supposed to generate a test report and update the check statuses. Any ideas for a workaround?

Also @igor-petrik-invitae were you able to figure out a way to make the actions work with dependabot?

[TobKed]

@igor-petrik-invitae @dgokcin is triggering labeler workflow on workflow_run by workflow pull_request_review with specified permissions like described in my comment https://github.com/actions/labeler/issues/12#issuecomment-1019246202 (PTAL on the airflow example) will not solve problem of permissions?

[dgokcin]

@TobKed I have not since I am having this issue on a branch not on a fork. The PR is created by the dependabot user. Do you think that the problem is happening because of the permisisons of the dependabot user?

[dgokcin]

Apparently, GitHub is treating dependabot prs like forks. Here is the related article. As @TobKed has suggested, I used the following snippet on the top level of my workflow to grant the needed permissions. So thank you very much.

permissions:
  # All other permissions are set to none
  checks: write
  contents: read
  pull-requests: write

Additional question to @TobKed assuming that the repository will always be private and I will only use dependabot to update private submodules that my repository is dependent to, do you think it is also possible/safe to use pull_request_target as my event trigger without adding any permissions like you have suggested?

[TobKed]

@dgokcin it is possible to use pull_request_target (actually I started to use it like that in my private repositories recently). Is it safe? I think yes, but I am not 100% sure about that. If it is related to some critical code I would suggest consultations with security specialists :)

[pedronastasi]

Apparently, GitHub is treating dependabot prs like forks. Here is the related article. As @TobKed has suggested, I used the following snippet on the top level of my workflow to grant the needed permissions. So thank you very much.

permissions:
  # All other permissions are set to none
  checks: write
  contents: read
  pull-requests: write

Additional question to @TobKed assuming that the repository will always be private and I will only use dependabot to update private submodules that my repository is dependent to, do you think it is also possible/safe to use pull_request_target as my event trigger without adding any permissions like you have suggested?

pull_request_target is not safe and not recommended at all as it compares all the changes against master, which makes the tests unreliable.