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?

[adityasharad]

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?

There are two relevant mechanisms for masking secrets:

• The Octokit.js library (which the CodeQL Action uses under the hood for GitHub API calls) replaces tokens with REDACTED before it logs the headers: see here. That's what you're seeing in the example above. For this reason I believe the CodeQL Action itself is never actually logging write tokens.
• Actions secrets that are printed as plain text get redacted (replaced with *s) in the Actions log UI: see https://docs.github.com/en/actions/learn-github-actions/workflow-commands-for-github-actions#masking-a-value-in-log and https://docs.github.com/en/actions/security-guides/encrypted-secrets#accessing-your-secrets.

[evverx]

For this reason I believe the CodeQL Action itself is never actually logging write tokens

As long as the CodeQL Action uses the library it's probably safe to say that it logs something with Octokit.js on errors at least and depending on the version of the library it could be anything unless the library is pinned to particular SHAs and gets reviewed when it's updated (which almost never happens)

Actions secrets that are printed as plain text get redacted

I don't think they are always redacted and that's probably why https://docs.github.com/en/actions/security-guides/encrypted-secrets#accessing-your-secrets says explicitly

Warning: GitHub automatically redacts secrets printed to the log, but you should avoid printing secrets to the log intentionally.

I think it would be better if the action would fail silently like, for example, labeler, which fails with something like

Error: HttpError: Resource not accessible by integration
Error: Resource not accessible by integration

https://github.com/evverx/systemd/runs/4199356475?check_suite_focus=true

[WaKeMaTTa]

I have this in my YAML file from private repo:

    permissions:
      id-token: write
      actions: read
      contents: read
      pull-requests: read
      security-events: write

But i still have the error:

Error: Advanced Security must be enabled for this repository to use code scanning.

Any solution?

[aeisenberg]

@WaKeMaTTa Make sure to enable advanced security on your repository. The docs are here.

If you are still seeing problems, please raise a new issue and include the relevant parts of the workflow.

[WaKeMaTTa]

@aeisenberg I don't have this option in our private repo:

[aeisenberg]

Please take a look at Enabling Advanced Security Features. You will need an enterprise account to enable Advanced Security on private repositories.

[OlugbengaJJ]

Hi, Kindly enable advance security using this Advance Github Security
Then go ahead and add these permission to your workflow for private repos.
permissions:
actions: read
contents: read
security-events: write
statuses: write

[jsoref]

Fwiw, it is possible to make things friendlier to users... I intend to include sarif handling in check-spelling with code like this:
https://github.com/check-spelling/check-spelling/blob/8e5f1a5eb8b1cf0da26fe3def6e3229d1cf0c6b9/unknown-words.sh#L1253-L1260
https://github.com/check-spelling/check-spelling/blob/8e5f1a5eb8b1cf0da26fe3def6e3229d1cf0c6b9/unknown-words.sh#L875-L878

Alternatively, if you want to actually take a full leap and just check to see if you go splat, you can do something like this:
actions/labeler@6390989

For an expected error, it's really cruel to force users to read through an http header dump instead of providing the information they need in an easy to digest format.

I'd be willing to private a PR of either form to this repository if someone expresses a willingness to review it (sadly the actions/labeler repository appears to be a 👻 town, so I'm not going to allocate resources for things that are unlikely to be reviewed).