Dependabot is failing to authenticate against a private Hex Repisotiry

[adamtharani]

Is there an existing issue for this?

• I have searched the existing issues

Package ecosystem

Hex

Package manager version

No response

Language version

Elixir

Manifest location and content before the Dependabot update

/directory/mix.exs

dependabot.yml content

version: 2

registries:
  fluxon-hex-repository:
    type: hex-repository
    repo: fluxon
    url: https://repo.fluxonui.com
    auth-key: "${{ secrets.FLUXON_HEX_REPO_AUTH_KEY }}"
    public-key-fingerprint: ${{ secrets.FLUXON_HEX_REPO_PUBLIC_KEY_FINGERPRINT }}
updates:
  - package-ecosystem: mix
    directory: "/"
    registries:
      - fluxon-hex-repository
    insecure-external-code-execution: allow
    schedule:
      interval: weekly
      day: thursday
    groups:
      production-dependencies:
        dependency-type: production
      dev-dependencies:
        dependency-type: development

Updated dependency

No response

What you expected to see, versus what you actually saw

The package manager is failing to update due to private_source_authentication_failure

Handled error whilst updating ash: private_source_authentication_failure {:source=>"fluxon"}

Native package manager behavior

No response

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

No response

Smallest manifest that reproduces the issue

No response

[frerich]

I'm seeing the same.

Tracing the HTTP calls done to the private repository, I can see that the authorization HTTP header is always empty instead of having whatever value is given to auth-key in the YAML file.

I see there's a unit test for this scenario (https://github.com/dependabot/dependabot-core/blob/main/hex/spec/dependabot/hex/update_checker_spec.rb#L387-L398) and that test seems to do the right thing. Can we debug how the value of auth-key in the YAML file ends up as a Dependabot::Credential key?

[frerich]

@sorentwo can you provide some guidance on how to tackle this? Does dependabot still work with the Oban repo?

[TylerWitt]

Is there a sample repo you could make? If it's just Oban I can try to figure it out.

[TylerWitt]

@frerich Try auth_key instead of the dashed version. I think the documentation is incorrect potentially.

[frerich]

@TylerWitt To reproduce this issue, you can clone https://github.com/frerich/dependabot_testbed -- it's just the result of mix new dependabot_testbed with one dependency added referencing a private acmecorp repo. After cloning it, you should set a HEX_REPO_AUTH_KEY secret in the cloned GitHub repo.

The .github/dependabot.yml file describes how to access that repo: I use a dynamically generated URL (https://webhook.site/d8ea1da7-8afc-4879-9998-65a3d765010f) which lets me inspect all requests sent by Dependabot. This shows how the authorization header is submitted - but it's empty.

Modifying the testspec/dependabot/hex/update_checker_spec.rb:391 however such that it uses the webhook.site URL and then running the test shows that it does submit the auth-key value.

So right now I'm speculating that it's something funny about how the YAML file is turned into a Dependabot::Credential object.

[TylerWitt]

@frerich I can confirm the YAML is being read correctly--but the credentials arg is an empty list when it hits the hex code.

Will keep digging.

[TylerWitt]

It is possible that this issue is happening before dependabot-core. As an example, it seems like dependabot-cli trims certain credential fields and then a proxy service injects them again. The dry-run also does not seem to function well with private repositories (in any language) unless you pass them in with LOCAL_CONFIG_VARIABLES...

[TylerWitt]

When I pass in the contents of my registries from the yaml

LOCAL_CONFIG_VARIABLES="[{\"type\":\"hex_repository\",\"repo\":\"dependabot\",\"url\":\"https://dependabot-private.fly.dev\",\"auth_key\":\"d6fc2b6n6h7katic6vuq6k5e2csahcm4\"}]"

into the dev container, and run the dry run on (my version) of your repository, it works.

So indeed, something about how execution is running for Elixir.

[TylerWitt]

@abdulapopoola Is it possible for me to debug this further? Or is it more likely something internal?

[abdulapopoola]

Thanks @TylerWitt , yes this will require some internal work, I've added this to our tracking board and hope to get back to you soon.