DO NOT MERGE: Require an organization key and store short-lived tokens - #1181
Draft
ericmj wants to merge 1 commit into
Draft
DO NOT MERGE: Require an organization key and store short-lived tokens#1181ericmj wants to merge 1 commit into
ericmj wants to merge 1 commit into
Conversation
ericmj
changed the title
mix hex.organization auth now requires --key; the key is exchanged for a short-lived token immediately and only the token is stored, never the key. Organization repositories no longer authenticate with a stored API key — they use the cached short-lived token or the user's OAuth authentication — and HEX_REPOS_KEY no longer grants access to organization repositories. For development, mix hex.user auth grants access to all your organizations. The base hexpm repository (including trusted mirrors authenticated with HEX_REPOS_KEY) is unchanged.
ericmj
force-pushed
the
organization-short-lived-tokens
branch
from
June 16, 2026 19:05
5c94711 to
dbe0b86
Compare
This was referenced Aug 28, 2026
brweber2
added a commit
to Cobenian/.github
that referenced
this pull request
Aug 28, 2026
) Hex >= 2.5.0 warns "Authenticating to the cobenian repository with a stored key is deprecated and will be removed" on every deps.get/hex.audit in every repo with private Cobenian deps. The warning's own CI advice is verbatim the command this step already runs, which makes it look like a live defect and invites two wrong fixes: rotating HEX_ORG_KEY, or switching to HEX_REPOS_KEY. Verified against the Hex 2.5.1 source that neither helps. The sole trigger is `repo_config.auth_key != nil` for a `hexpm:<org>` repo, in Hex.Repo.build_hex_core_config/3 (lib/hex/repo.ex:325); the key's type, age and permissions are never inspected, and `hex.organization auth --key` is exactly what stores auth_key (lib/mix/tasks/hex.ex:280). HEX_REPOS_KEY only selects the sibling :env branch, which is deprecated too. The non-deprecated path is OAuth, whose token has no env var (lib/hex/state.ex:18) and is written only by the interactive `mix hex.user auth` device flow. Upstream owns it: hexpm/hex#1207 (merged after 2.5.1 shipped) stops the warning for organization-owned keys, and hexpm/hex#1181 deliberately preserves this command through the breaking change. This step is already the forward-compatible form, so this commit is comment-only — no behaviour change, and no reason to pin Hex, which would only hold the warning still. Two Hex 2.6 items that are NOT settled are recorded for follow-up: whether HEX_ORG_KEY is organization-owned or user-owned (only the former keeps working), and the ~30 min no-refresh token's auth-immediately-before-fetch requirement, which this workflow satisfies but product Dockerfiles must too. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to the deprecations in #1179 — this is the breaking change that removes the deprecated paths. It must ship in a release after the one that carries the deprecation warnings, not together with them. Draft until then.
What changes
mix hex.organization auth ORGANIZATIONnow requires--key. Without it, the task raises and points tomix hex.user auth(development) ormix hex.organization key … generate(CI).mix hex.organization auth ORGANIZATION --key KEYnow exchanges the key for a short-lived token immediately and stores only the token, never the key. The exchange also verifies the key grants access to the organization.auth --key) or, failing that, the user'smix hex.user authauthentication. A storedauth_keyleft inhex.configby an older client is ignored.HEX_REPOS_KEYno longer grants access to organization repositories — authenticate per organization withauth --keyinstead.Scope / compatibility
hexpmrepository is unchanged, including trusted mirrors authenticated withHEX_REPOS_KEY. Full removal ofHEX_REPOS_KEYis intentionally out of scope here because it is also used for mirror authentication.client_credentialsexchange itself is unchanged, so CI keeps working: a job runsmix hex.organization auth ORGANIZATION --key $KEYand fetches with the resulting token. Since that exchange issues no refresh token, the token must be re-obtained after it expires (~30 min) — fine for a typical CI job, and the intended friction for a human pasting a key on a workstation.Follow-up (separate, later)
The hexpm server should eventually reject the exchange of a user-owned key for repository scopes (returning
invalid_scope), so the constraint reaches clients that are pinned to old Hex versions. That is deliberately deferred — it is a server-side breaking change to be timed against customer comms, and it is not part of this PR.