Record key ownership when authenticating organizations#1207
Merged
Conversation
The stored-key deprecation warning recommends mix hex.organization auth ORG --key KEY, but following it did not silence the warning because the client could not tell an organization-owned key from a user-owned key once stored. Extract the key owner from the GET /api/auth response when verifying the key and store it as auth_key_owner on the repo config. Organization keys no longer warn and print a note about the Hex 2.6 token exchange, user keys warn that they stop working in Hex 2.6, and keys stored before this version keep warning until the command is re-run. Servers that respond 204 without owner information behave as before.
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.
Following the stored-key deprecation warning's own instructions (generate an organization key, pass it with
mix hex.organization auth ORG --key KEY) didn't silence it, because the client can't tell an organization-owned key from a user-owned key once it's stored. CI logs stay full of the warning even for correctly configured organization keys.mix hex.organization auth ORG --key KEYnow reads the key owner from the GET /api/auth response used to verify the key (hexpm/hexpm#1746) and stores it asauth_key_owneron the repo config. At fetch time, organization-owned keys don't warn anymore, user-owned keys warn that they stop working in Hex 2.6, and keys stored before this version keep the old warning plus a hint to re-run the auth command to record the owner. The HEX_REPOS_KEY warning also names Hex 2.6 now instead of "will be removed". Authenticating with an organization key prints a note that Hex 2.6 will exchange the key for a short-lived token, so CI should run auth right before fetching.Against a server that doesn't return owner information yet, everything behaves as before, so this doesn't depend on the hexpm deploy ordering.