Skip to content

Prime user's git credentials after authenticating with gh #1434

Description

@mislav

After successfully authenticating with GitHub CLI #1413, we could potentially prime the user's git credential cache with a token that can be used for git clone/push/pull operations.

What this solves: users would no longer get another authentication prompt (this time from git, but the user typically doesn't know that) right after they've authenticated gh and ran something like gh repo clone myrepo. Furthermore, if the user has 2FA enabled, even though the git prompt asks them for their github.com password, their actual password will not work and they will have to generate a Personal Access Token. However, at this point in GitHub CLI we already have a token for them that is valid for git operations.

How this would work, roughly:

$ git config --global credential.helper
osxkeychain

$ git credential-osxkeychain
usage: git credential-osxkeychain <get|store|erase>

# getting an existing token
$ git credential-osxkeychain get <<<"host=github.com
protocol=https"

password=TOKEN
username=mislav

# setting a new token (old one needs to be `erase`d first)
$ git credential-osxkeychain store <<<"host=github.com
protocol=https
username=mislav
password=NEWTOKEN"

See https://git-scm.com/docs/git-credential

Risks:

  • With Git for Windows and its default credential helper, requesting a cached credential could spawn a graphical window asking to log into GitHub if there is no stored credential. We would definitely want to avoid that.
  • Depending on OS permissions and the configured credential helper, gh executable might not have the privileges to check or store git credentials.
  • There might be no credential helper configured for the user on Linux. In those cases, it would be hard to pick a default for a user, so we should probably bail out in that case, but we could provide the user with some pointers.

Activity

  1. added
    authrelated to tokens, authentication state, or oauth
    on Jul 27, 2020
  2. added
    coreThis issue is not accepting PRs from outside contributors
    on Oct 7, 2020
  3. mislav commented on Nov 16, 2020

    @mislav
    ContributorAuthor

    If the user already has SSH keys in their ~/.ssh directory, GitHub CLI could offer to default to SSH protocol for cloning/pushing and ensure that the public SSH key is uploaded to the user's account.

    If there are no local SSH keys, but the user indicates that they would still like to use SSH for authentication (e.g. if their org mandates it), we could guide the person through the process of generating a new SSH key and upload the resulting public key to the GitHub account, so that the user could be quickly up-and-running on a fresh machine. Idea by @LeonardAukea 🙇

  4. self-assigned this
    on Nov 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

authrelated to tokens, authentication state, or oauthcoreThis issue is not accepting PRs from outside contributorsenhancementa request to improve CLI

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions