Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
XVilka opened this issue Jun 18, 2021 · 20 comments
Open

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

XVilka opened this issue Jun 18, 2021 · 20 comments

Comments

@XVilka
Copy link

XVilka commented Jun 18, 2021

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
Copy link

tausbn commented Jun 18, 2021

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
Copy link
Author

XVilka commented Jun 18, 2021

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

@robertbrignull
Copy link
Contributor

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.
Screenshot 2021-06-18 at 11 30 10

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
Copy link

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
Copy link
Contributor

@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
Copy link

@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
Copy link
Contributor

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
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor

@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
Copy link

evverx commented Nov 14, 2021

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
Copy link
Contributor

adityasharad commented Nov 15, 2021

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:

@evverx
Copy link

evverx commented Nov 15, 2021

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
Copy link

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
Copy link
Contributor

@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
Copy link

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

image

@aeisenberg
Copy link
Contributor

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

Tatsumi0000 added a commit to Tatsumi0000/MobSF-Practice that referenced this issue May 7, 2022
@OlugbengaJJ
Copy link

OlugbengaJJ commented May 26, 2022

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
Copy link
Contributor

jsoref commented Oct 9, 2022

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).

johnandersen777 pushed a commit to johnandersen777/static-builds that referenced this issue Mar 26, 2023
Ivypas added a commit to Ivypas/cloud-native-spring-in-action-config-service that referenced this issue May 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests