BUG: githubv4.Query: Resource not accessible by integration in Branch-Protection

[laurentsimon]

An interesting error came up in the run for the GitHub action https://github.com/ossf/scorecard/security/code-scanning/2869?query=ref%3Arefs%2Fheads%2Fmain

error during branchesHandler.setup: internal error: githubv4.Query: Resource not accessible by integration

Note: this was for a push event, not a PR. Let's see if this continues in next push. It did not happen before in previous pushes.

I've never seen it before. @azeemsgoogle ideas?

[azeemshaikh38]

Possibly similar to https://github.com/actions/first-interaction/issues/10. Need to investigate further.

[laurentsimon]

This seems to still be occurring: https://github.com/ossf/scorecard/security/code-scanning/2869?query=ref%3Arefs%2Fheads%2Fmain

[laurentsimon]

another occurrence in https://github.com/step-security/agent/issues/35#issuecomment-974274585

[laurentsimon]

another one https://github.com/ossf/scorecard/issues/1074#issuecomment-973479064

[laurentsimon]

Apparently, this happened all the time in https://github.com/step-security/agent/issues/35#issuecomment-974585033 @varunsh-coder does the problem occur on pull requests or on push events to main branch?

[varunsh-coder]

Apparently, this happened all the time in step-security/agent#35 (comment) @varunsh-coder does the problem occur on pull requests or on push events to main branch?

I see this error both for pull requests and push. BTW this error is probably due to a token permissions issue. The workflow only has security-events: write. Are you calling a GitHub API to get this result?

[laurentsimon]

I agree it looks like a permission problem. We use permissions: read-all and security-events: write; and this error only happens for the Branch Protection APIs using graphQl.

Mhhhh.. this page https://docs.github.com/en/graphql/guides/forming-calls-with-graphql states To communicate with the GraphQL server, you'll need an OAuth token with the right scopes. I think that's the cause. We're using the GitHub token provisioned to the workflow, but it's not an OAuth or PAT.

If that's the reason, looks like we would either need to use the RESTful APIs for the GitHub action, or disable branch protection in GitHub action. We initially moved away from REST APIs to graphQl because of rate limiting. In the case of a GitHub action, developers only need to access their own repo so we don't really need to worry about rate limiting: that seems to be confirmed since other checks use REST APIs and appear to be working as expected.

@azeemsgoogle wdut?

[laurentsimon]

@josepalafox the graphQl APIs seem to require a PAT/OAuth token and don't automatically work with the GitHub token provisioned to workflows. Do you know the reasoning behind this? Is there a particular permission needed for the workflow GitHub token to make this work?

[varunsh-coder]

I agree it looks like a permission problem. We use permissions: read-all and security-events: write; and this error only happens for the Branch Protection APIs using graphQl.

Mhhhh.. this page https://docs.github.com/en/graphql/guides/forming-calls-with-graphql states To communicate with the GraphQL server, you'll need an OAuth token with the right scopes. I think that's the cause. We're using the GitHub token provisioned to the workflow, but it's not an OAuth or PAT.

If that's the reason, looks like we would either need to use the RESTful APIs for the GitHub action, or disable branch protection in GitHub action. We initially moved away from REST APIs to graphQl because of rate limiting. In the case of a GitHub action, developers only need to access their own repo so we don't really need to worry about rate limiting: that seems to be confirmed since other checks use REST APIs and appear to be working as expected.

@azeemsgoogle wdut?

JFYI - I realized that looking up branch protection requires administration permission, and I believe GITHUB_TOKEN does not have administration permission. So even if Graph API had the same permission model, I doubt this would work with the GITHUB_TOKEN...

[laurentsimon]

Interesting, thanks for sharing! I don't understand why the GitHu tokens have different permission models though :/

[josepalafox]

The issue is that the generic actions does not get the right permissions. User will need to generate PAT and store as a secret to use in actions. This can be described as a configuration step.

On Thu, Dec 2, 2021, 16:49 laurentsimon @.***> wrote:

Interesting, thanks for sharing!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ossf/scorecard/issues/1097#issuecomment-985120860, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPN2EQMJGB7BIJEF7UY2TUPAH2ZANCNFSM5FFVKYEA .

[laurentsimon]

Thanks for the info! Do you know the reasoning behind this? Is there a security concern? Or is this something that may get fixed in the future?

[josepalafox]

This is evidently an intentional design limitation and exists across multiple API services for security purposes.

On Fri, Dec 3, 2021, 10:57 laurentsimon @.***> wrote:

Thanks for the info! Do you know the reasoning behind this? Is there a security concern? Or is this something that may get fixed in the future?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ossf/scorecard/issues/1097#issuecomment-985754168, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPN2BFNOUVKIYWYZ6M4RLUPEHKFANCNFSM5FFVKYEA .

[azeemshaikh38]

The issue is that the generic actions does not get the right permissions.

@laurentsimon, if this is the case, then moving to REST API won't solve the problem. Basically, we'll need PAT if we want to run Branch-Protection. Have you tried running the Action without the Branch-Protection check if that works?

[laurentsimon]

yes I meant to mention that. It may be the case that REST APIs will never work. I have a TODO item to test it out in the action using curl. Will post my result. But I'm afraid you''re right, @azeemshaikh38

[azeemshaikh38]

SG. Will assign this to you for now. Can close this issue after confirming.

[laurentsimon]

@josepalafox reviving this thread. As we try to make scorecard as friction-less as possible for installation, we realize the PAT requirement does create friction. I wanted to understand what you meant by This is evidently an intentional design limitation and exists across multiple API services for security purposes.

What can workflow tokens not expose a read permission to read branch protection settings? What is the security concern? I know there's a new token-id permission that was introduced for OIDC, for example.

[josepalafox]

I was sort of just repeating an answer I was given internally. I'll poke around. My general sense is that you don't want to expose all the branch protection rules because it essentially explains what review policies are for contributions.

On Wed, Jan 26, 2022 at 8:06 AM laurentsimon @.***> wrote:

@josepalafox https://github.com/josepalafox reviving this thread. As we try to make scorecard as friction-less as possible for installation, we realize the PAT requirement does create friction. I wanted to understand what you meant by This is evidently an intentional design limitation and exists across multiple API services for security purposes.

What can workflow tokens not expose a read permission to read branch protection. What is the security concern? I know there's a new token-id permission that was introduced for OIDC, for example.

— Reply to this email directly, view it on GitHub https://github.com/ossf/scorecard/issues/1097#issuecomment-1022347562, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPN2BROSONXQEOIOYO47DUYALXPANCNFSM5FFVKYEA . You are receiving this because you were mentioned.Message ID: @.***>

-- Jose Palafox Technical Partnerships and Engineering @ GitHub @.*** 503.877.2403

[laurentsimon]

Thanks Jose. Let us know what you find.

So long as the permission is controlled by a workflow field, it does not strike me as being more dangerous than id-token or contents:write or packages:write.

[josepalafox]

Feedback from our team is that to get branch protection rules you'd have to have admin:read which is too broad to enable.

cc @cschleiden

[laurentsimon]

Thanks for the info. Fyi, branch protection is accessible with a PAT owned by a non-repo maintainer, except 3 settings that require admin:read as as repo maintainer. I'd expect the same should work for a workflow token. I don't follow why admin:read for the repo itself should be necessary to read other settings, since it's available publicly anyway.

Also, in general, using ephemeral workflow tokens is beneficial because PATs cannot be rotated easily.

Let me know if I mis-understood something.

[Hritik14]

Hi. It's been a while since this issue is open. Is there any support planned for private repos ?

I found the following on the scorecard actions docs.

Private repositories need a PAT to use any Scorecard Action functions ... We recommend that you do not use a PAT unless you feel that the risks introduced are outweighed by the functionalities they support.

This implies using scorecard on private repositories is risky by design...

[eddie-knight]

I'm getting the following error at the moment:

2023/07/27 14:52:26 error during command execution: check runtime error: Branch-Protection: internal error: error during branchesHandler.setup: internal error: githubv4.Query: Your token has not been granted the required scopes to execute this query. The 'allowsDeletions' field requires one of the following scopes: ['public_repo'], but your token has only been granted the: [''] scopes. Please modify your token's scopes at: https://github.com/settings/tokens.

Edit: I resolved this with the following scope change on my token:

I believe GitLab users solved it like this:

[spencerschrock]

Hi. It's been a while since this issue is open. Is there any support planned for private repos ?

I found the following on the scorecard actions docs.

Private repositories need a PAT to use any Scorecard Action functions ... We recommend that you do not use a PAT unless you feel that the risks introduced are outweighed by the functionalities they support.

This implies using scorecard on private repositories is risky by design...

The fine-grained PAT should help aleviate this. But we'll need to update our instructions at: https://github.com/ossf/scorecard-action#authentication-with-fine-grained-pat-optional

It will probably also need read permissions to a few more fields for private repos (I'm guessing actions, issues, pull_requests, contents, but just a guess not exhaustive.

I'm getting the following error at the moment: 2023/07/27 14:52:26 error during command execution: check runtime error: Branch-Protection: internal error: error during branchesHandler.setup: internal error: githubv4.Query: Your token has not been granted the required scopes to execute this query. The 'allowsDeletions' field requires one of the following scopes: ['public_repo'], but your token has only been granted the: [''] scopes. Please modify your token's scopes at: https://github.com/settings/tokens.

I believe this has been resolved in the slack, but the classic PATs need the public_repo scope to read branch protection, which the message is saying.

Note: Hopefully all of this will be a problem of the past soon due to Repository Rules (see: #3326)

[afmarcum]

Document on the Scorecard repo pointing to the scorecard-action documentation, which may need to be updated for clarity as well.

[mauricio-liatrio]

I ran into the same exact error of this issue, I do have a private repo with branch protection. I resolved it by adding these two permissions to my PAT:

The documentation needs to be updated!!