Change of behavior "Error: Resource not accessible by integration"

[XVilka]

It started to happen two days ago without any relevant change from our side in all PRs:

rizinorg/rizin#1222

Here is our CodeQL action configuration:
https://github.com/rizinorg/rizin/blob/dev/.github/workflows/code-analysis.yml

The error message is the following:

https://github.com/rizinorg/rizin/pull/1222/checks?check_run_id=2855028592#step:4:1

RequestError [HttpError]: Resource not accessible by integration
    at /home/runner/work/_actions/github/codeql-action/v1/node_modules/@octokit/request/dist-node/index.js:66:23
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async Job.doExecute (/home/runner/work/_actions/github/codeql-action/v1/node_modules/bottleneck/light.js:405:18) {
  name: 'HttpError',
  status: 403,
  headers: {
    'access-control-allow-origin': '*',
    'access-control-expose-headers': 'ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, Deprecation, Sunset',
    connection: 'close',
    'content-encoding': 'gzip',
    'content-security-policy': "default-src 'none'",
    'content-type': 'application/json; charset=utf-8',
    date: 'Fri, 18 Jun 2021 03:41:52 GMT',
    'referrer-policy': 'origin-when-cross-origin, strict-origin-when-cross-origin',
    server: 'GitHub.com',
    'strict-transport-security': 'max-age=31536000; includeSubdomains; preload',
    'transfer-encoding': 'chunked',
    vary: 'Accept-Encoding, Accept, X-Requested-With',
    'x-content-type-options': 'nosniff',
    'x-frame-options': 'deny',
    'x-github-media-type': 'github.v3; format=json',
    'x-github-request-id': '0405:5D98:A0F49:119F3A:60CC1600',
    'x-ratelimit-limit': '5000',
    'x-ratelimit-remaining': '4848',
    'x-ratelimit-reset': '1623989200',
    'x-ratelimit-resource': 'core',
    'x-ratelimit-used': '152',
    'x-xss-protection': '0'
  },
  request: {
    method: 'PUT',
    url: 'https://api.github.com/repos/rizinorg/rizin/code-scanning/analysis/status',
    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': 'CodeQL-Action/1.0.2 octokit-core.js/3.1.2 Node.js/12.13.1 (linux; x64)',
      authorization: 'token [REDACTED]',
      'content-type': 'application/json; charset=utf-8'
    },
    body: '{"workflow_run_id":948607521,"workflow_name":"Code scanning","job_name":"build","analysis_key":".github/workflows/code-analysis.yml:build","commit_oid":"3dc5ffebacc2420e860f67c3dfcfe08fcf87e09d","ref":"refs/heads/codeql-fixes","action_name":"init","action_ref":"v1","action_oid":"unknown","started_at":"2021-06-18T03:41:51.948Z","action_started_at":"2021-06-18T03:41:51.948Z","status":"starting","matrix_vars":"{\\n  \\"name\\": \\"CodeQL-cpp\\"\\n}"}',
    request: { agent: [Agent], hook: [Function: bound bound register] }
  },
  documentation_url: 'https://docs.github.com/rest'
}
Error: Resource not accessible by integration

[tausbn]

Thank you for your report!

I wonder, could this be related to the following issue? #464

It looks to be the same error. Could it be that the permissions on your repo were changed recently?

[XVilka]

We didn't touch, and this is set to RW:

[robertbrignull]

You can actually see in a workflow run what permissions it has. It gets printed out near the top. In your run it did appear to have write permission, so it seems like a different class of bug than others where the workflow runs with read permissions for some reason.

I do note that there have been passing runs since, including runs on the push event. So I'd hope perhaps this is just a one-off.

[AlCalzone]

I'm getting the same error, but only for commits where Dependabot merged one of its PRs. These are showing the following error:

Error: Workflows triggered by Dependabot on the "push" event run with read-only access. Uploading Code Scanning results requires write access. To use Code Scanning with Dependabot, please ensure you are using the "pull_request" event for this workflow and avoid triggering on the "push" event for Dependabot branches. See docs.github.com/en/code-security/secure-coding/configuring-code-scanning#scanning-on-push for more information on how to configure these events.

The highlighted part does not really help, because this affects pushes to master, not pull requests or Dependabot's branches.

[robertbrignull]

@AlCalzone, check out the "analysis still failing on the default branch" section of #416. Apologies this information is not yet in the proper troubleshooting docs but that change is in progress and we'll update the error message to point there when done.

[AlCalzone]

@robertbrignull Unfortunately this is not a solution for me

From what we can tell the only case where this can happen is if the dependabot PR is merged by using the @dependabot squash and merge syntax. Our advice would be to avoid using this syntax if at all possible. Thankfully the new feature to automatically merge a pull request may be able to help here and fulfil the same functionality.

I'm using an action to determine whether dependabot PRs should be merged automatically, based on the dependency type and version bump. The built-in auto-merge functionality is simply not granular enough for this.

That action is using the @dependabot squash and merge syntax to let Dependabot handle the merge queue, including automatically rebasing when conflicts happen.
Rebasing also seems to trigger even when there are no actual merge conflicts, so there must be something else that Dependabot does. I might be mistaken though - if it is okay to just merge those PRs when there is no merge conflict, triggering GitHub's auto-merging from the action might be a solution.

[robertbrignull]

I'm sorry it's a bit of a pain. It's an annoying consequence of various bits of valid behaviour. The core behaviour to understand is that code scanning analysis won't work on commits authored solely by dependabot, except when analysing a pull request. I hope you'll be able to jig your CI to prevent this case. Unfortunately the only alternative would be to manually restart any analyses that fail because of this reason, as they'll work on the second try because a non-dependabot actor has triggered them.

[AlCalzone]

Would it be possible to add a condition to the default CodeQL job to skip these impossible-to-build commits? Something like github.actor != 'dependabot-bot' || github.event_name != 'push'.

[martinschaef]

Uploading SARIF files started failing for me about 24 hours ago. Here is an example of the failure.

Here and here are examples of the container uploading the SARIF file successfully a few days ago.

I didn't touch the SARIF part, but I did change how I authenticate with AWS. I switched from using GitHub Secrets to using the Open ID connect and added the permissions block in the action.

Could the permissions block be the reason? If so, what do I need to add?

[martinschaef]

Answering my own question:
I need the permissions block, otherwise the OpenID connect fails and it has to look like this:

permissions:
    id-token: write
    contents: write              # This is required for actions/checkout@v1
    security-events: write   # To upload sarif files

[adityasharad]

@martinschaef you are correct that you have to configure the permissions block accordingly. If a particular permission is not mentioned in the permissions block then it gets set to none.

The minimal permissions that should be needed for a workflow to use the CodeQL Action are mentioned in the example workflow at https://github.com/github/codeql-action#usage: security-events: write, and for private repos contents: read and actions: read. This assumes you are using actions/checkout@v2.

To address some earlier questions in the thread, Dependabot runs will now respect the permissions block.

[evverx]

Looking at

    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': 'CodeQL-Action/1.0.2 octokit-core.js/3.1.2 Node.js/12.13.1 (linux; x64)',
      authorization: 'token [REDACTED]',
      'content-type': 'application/json; charset=utf-8'
    },

I think either codeql replaces tokens with [REDACTED] itself or more likely GitHub does that to prevent codeql from printing tokens to the log. I wonder if it would be possible not to log tokens with write permissions?