Private git registry for GitHub breaks any updates referencing it

[stevehipwell]

Is there an existing issue for this?

• I have searched the existing issues

Package ecosystem

github-actions, terraform

Package manager version

n/a

Language version

n/a

Manifest location and content before the Dependabot update

n/a

dependabot.yml content

version: 2

registries:
github:
type: git
url: https://github.com
username: x-access-token
password: ${{ secrets.REPO_TOKEN }}

updates:

• package-ecosystem: github-actions
  registries: "*"
  directory: /
  schedule:
  interval: daily

• package-ecosystem: terraform
  registries: "*"
  directory: /
  schedule:
  interval: daily

Updated dependency

n/a

What you expected to see, versus what you actually saw

I'd expect for this to work correctly, and it was 28 days ago.

I now get the following error (org and repo obfuscated).

proxy | time="2022-11-15T17:08:57Z" level=info msg="proxy starting" commit=843c0928fee6f7a20d835e4f6c436aa7c1567af9
proxy | 2022/11/15 17:08:57 Listening (:1080)
updater | 2022-11-15T17:08:57.559632541 [513060554:main:WARN:src/devices/src/legacy/serial.rs:214] Detached the serial input due to peer close/error.
updater | time="2022-11-15T17:09:00Z" level=info msg="guest starting" commit=ed384b44fcafed3f83e13235c1143eb2afa85db1
updater | time="2022-11-15T17:09:00Z" level=info msg="starting job..." fetcher_timeout=10m0s job_id=513060554 updater_timeout=45m0s updater_version=305f8025b0eaa2a86586286dbe23da475c0a3fbc
updater | I, [2022-11-15T17:09:03.030567 #7] INFO -- sentry: ** [Raven] Raven 3.1.2 ready to catch errors
updater | INFO <job_513060554> Starting job processing
proxy | 2022/11/15 17:09:07 [002] GET https://api.github.com:443/repos/my-org/my-repo
proxy | 2022/11/15 17:09:07 [002] * authenticating github api request
proxy | 2022/11/15 17:09:07 [002] 401 https://api.github.com:443/repos/my-org/my-repo
updater | ERROR <job_513060554> Error during file fetching; aborting
updater | INFO <job_513060554> Finished job processing
updater | INFO Results:
updater | Dependabot encountered '1' error(s) during execution, please check the logs for more details.
updater | time="2022-11-15T17:09:07Z" level=info msg="task complete" container_id=job-513060554-file-fetcher exit_code=0 job_id=513060554 step=fetcher
updater | time="2022-11-15T17:09:07Z" level=warning msg="failed during fetch, skipping updater" job_id=513060554

Native package manager behavior

n/a

Images of the diff or a link to the PR, issue, or logs

n/a

Smallest manifest that reproduces the issue

n/a

[stevehipwell]

This might not be a bug, as this error happens with an expired token. I still think it's a bug as non-private repo dependencies weren't handled as Dependabot errored out early.

[jeffwidman]

👋 sorry for the slow response.

Looking at the logs, the problem here is that Dependabot couldn't even fetch the repo to run the job against:

updater | INFO <job_513060554> Starting job processing
proxy | 2022/11/15 17:09:07 [002] GET [https://api.github.com:443/repos/my-org/my-repo](https://api.github.com/repos/my-org/my-repo)
proxy | 2022/11/15 17:09:07 [002] * authenticating github api request
proxy | 2022/11/15 17:09:07 [002] 401 [https://api.github.com:443/repos/my-org/my-repo](https://api.github.com/repos/my-org/my-repo)
updater | ERROR <job_513060554> Error during file fetching; aborting
updater | INFO <job_513060554> Finished job processing
...
updater | time="2022-11-15T17:09:07Z" level=warning msg="failed during fetch, skipping updater" job_id=513060554

It doesn't have anything to do with the actual deps mentioned in the manifests--regardless of whether those are public or private, if Dependabot can't clone the repo it's trying to process, it won't have any idea what the deps even are!

I'm going to close, but if for some reason I misunderstand and you still encounter this same error even after refreshing the token, then comment and we can re-open.

[stevehipwell]

@jeffwidman shouldn't Dependabot either just not use expired tokens or re-try without a custom token if the auth fails? This would reduce the blast radius of an expired token blocking all updates including ones which could be calculated without the custom token. I guess better UI feedback could also mitigate this somewhat. I'm happy to open a new issue or you could re-open this one?

[jeffwidman]

At the top of the screen where you saw the job logs, I thought it displayed an error saying that the repo was unreachable?

Because we generally do try to highlight errors like this a bit more visibly than just buried in the logs.

Feel free to post a screenshot of what you're seeing. And if you're not seeing an error, then maybe we need to tweak how we catch that exception.

As far as not trying a failed token, Dependabot doesn't know until it tries if the token will work for that repo. IMO it's kinda pointless to validate ahead of time because we are essentially doing that when it tries to clone the repo. And we can't just look at your users access rights because there are scenarios, particularly for large companies, where they want to limit the scope of what Dependabot has access to for security reasons.

I think the main issue here that I see is Dependabot should loudly notify when it fails to work, and not wait for you to go digging. There's some work already in flight to improve that, but unfortunately it's still a ways out from being publicly visible.

[stevehipwell]

@jeffwidman I had to click through to the Insights > Dependency Graph screen to get any feedback that there was an issue with Dependabot; that's not great UX to start with. Making it much clearer that there is an issue should be table stakes for a product like this or else it's essentially no better than manual checks, if I have to check on Dependabot I might as well have manually checked my dependencies as I can't trust the automation to notify me when I might be insecure.

For the actual issue; are GitHub tokens opaque or are they JWTs (or similar)? If they're JWTs then expiry could easily be verified, if not it'd be easy to hit an always public repo (such as this one) using the token to see if it's valid before using it?