Skip to content

[BUG] Public release lookup fails when an ambient GitHub token is rejected #2833

Description

Describe the bug
The Unix installer resolves GITHUB_APM_PAT, GITHUB_TOKEN, or GH_TOKEN and attaches the selected credential to its first release-metadata request. When a credential is rejected, the response can lack tag_name and installation exits with Invalid API response received, even when the same public APM release metadata is accessible anonymously.

This makes bootstrap of a public CLI unnecessarily depend on an ambient credential's validity or authorization. Public CLI installation and authentication for subsequently consumed private packages are separate operations.

Public evidence:

To Reproduce

  1. Use an isolated installer harness with a non-secret dummy credential in one of the supported token environment variables.
  2. Stub the canonical public release-metadata request to return an authentication rejection when Authorization is present, and valid release metadata when it is absent.
  3. Run the installer with no pinned VERSION and observe that the current flow does not retry the rejected public metadata request anonymously before reporting failure. Stub subsequent downloads/install operations to keep the reproduction hermetic.

Expected behavior

  • Fetch public APM release metadata without making a rejected ambient token a prerequisite for success.
  • Preserve credential-aware recovery for anonymous rate limits; do not simply revert fix: send auth header for GitHub release lookup in installer and self-update #1588 and reintroduce the shared-IP failure.
  • Bound fallback to an explicitly public bootstrap context. Preserve private repository, GHES, enterprise mirror, and no-direct-fallback semantics; do not turn authorization failures into a general policy bypass.
  • Keep credentials scoped to the intended host. Never send GitHub tokens to configured mirror hosts or log token values.
  • Report HTTP/auth/rate-limit/network failures accurately, with an appropriate next action, rather than conflating them with malformed metadata or a private repository.
  • Assess the corresponding release lookup used by apm self-update and platform installers so equivalent public-bootstrap paths remain consistent. Do not rewrite package authentication as part of this fix.
  • Add regression cases for accepted/rejected/missing credentials, anonymous rate limits, pinned versions, private repositories, and fail-closed mirror behavior.

Environment (please complete the following information):

  • OS: macOS / Linux for the confirmed Unix installer path.
  • Python Version: N/A for this shell metadata request.
  • APM Version: v0.29.0 installer; same content at main revision 13386d9937f92aa0105c59fc3c4b7bbff4a7c6d2.
  • VSCode Version (if relevant): N/A.

Logs
N/A. The reproduction should use synthetic HTTP responses, not real credentials or organization-specific logs.

Additional context
Documenting a particular token lifetime or asking users to replace their primary credential is not the fix for downloading a public release. Private dependency access must continue to require the authorization appropriate to that dependency. #2788 is a separate proposal for credential diagnostics; it does not remove this bootstrap failure.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    type/bugSomething does not work as documented.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions