Set up git authentication when logging in to gh by mislav · Pull Request #2449 · cli/cli

mislav · 2020-11-20T19:31:04Z

This sets up git HTTPS credentials after successfully logging in to GitHub CLI. As a proof of concept, observe the last step in the flow:

$ gh auth login
? What account do you want to log into? GitHub.com
- Logging into github.com
? You're already logged into github.com as mislav. Do you want to re-authenticate? Yes
? How would you like to authenticate? Login with a web browser

! First copy your one-time code: XXXX-XXXX
- Press Enter to open github.com in your browser...
✓ Authentication complete. Press Enter to continue...

? Choose default git protocol HTTPS
- gh config set -h github.com git_protocol https
✓ Configured git protocol
? Authenticate Git with your GitHub credentials? Yes
✓ Logged in as mislav

On a fresh system, the user is now able to clone/push/pull from GitHub.com with no extra intervention, provided that they have a git credential helper defined (likely already the case on macOS and Windows).

Fixes #1434

TODO:

~~If the user selected SSH protocol, offer to upload their public keys~~ - followup
Decide whether to override existing cached HTTPS credentials
Handle the case when a git credential helper isn't configured
~~Enable non-interactive credential priming via flag~~ - decided against
Bring auth refresh up to parity with credential handling in auth login
~~Include checking git credential status in auth status~~ - cannot safely do. Since we do not know which credential helper the user has configured, using git credential approve to read their stored credential might cause their credential helper to interactively prompt the user for credentials, and that's something we cannot allow during auth status.
tests

ampinsk · 2020-11-23T17:35:33Z

This looks great so far! Just flagging this for later: Set up git for passwordless push/pull operations? is a bit confusing, happy to collab on the copy 👍

mislav · 2020-11-23T19:37:51Z

I've updated this branch to solve what to me was a pretty hard problem: what do we do if the user selects "HTTPS" authentication, but does not have any credential.helper configured? (I expect that, commonly, this would be Linux users on a fresh machine.)

The credential helper is a program that stores usernames & passwords for git operations over the HTTPS protocol. Git allows this to be configurable because people have different preferences for how they want to securely store authentication info. The default credential helper on macOS is osxkeychain that stores credentials in the user's login Keychain, and on Windows it's Git-Credential-Manager-Core that ships with Git for Windows. Sometimes, though, there will be no default, and we need to decide what to do.

We cannot really configure or recommend any single 3rd-party program as a credential helper because we do not know what program would be available and reliable for their platform. Git itself ships with two built-in credential helpers: cache and store, but neither are a good default in my opinion:

git-credential-cache only caches credentials for a short period of time;
git-credential-store stores tokens in a plain-text file, which isn't great because gh itself stores its tokens in a plain text file too, which we intend to fix in the future feat: Support for storing OAuth token in encrypted keychain #449.

However, what if gh itself was a credential helper? The git credential protocol is not complex, and gh already has access to an authentication token that can be used for cloning.

In the absence of a credential helper, gh now configures this in the user's ~/.gitconfig:

[credential "https://github.com"]
        helper = !gh auth git-credential

The new (hidden) auth git-credential command now answers credential queries from git at authentication time and ensures that git clones/pulls/pushes to GitHub.com (or to a GHES instance) are authenticated with the set of credentials stored by GitHub CLI. 👌

@ampinsk Yes, let's think about alternatives! We do have to ask something, because this operation should never initiate unprompted. The gist of what we need to ask is, even though most gh operations are by now successfully authenticated, we still need to configure your git so that clone/push/pull works without a hitch.

vilmibm

Thrilled with this! I am a fan of the credential store hack 👍

billygriffin · 2020-11-23T23:20:27Z

pkg/cmd/auth/login/login.go

+		if !isOurCredentialHelper(helper) {
+			var primeCredentials bool
+			err = prompt.SurveyAskOne(&survey.Confirm{
+				Message: "Set up git for passwordless push/pull operations?",


Was thinking something similar to @ampinsk - curious how something like this feels.

Suggested change

Message: "Set up git for passwordless push/pull operations?",

Message: "Also set up Git authentication for GitHub CLI operations that leverage Git?",

@billygriffin The idea is that more git operations than just ones initiated by gh are affected. For example, after doing this step, you can safely git clone <url> (bypassing GitHub CLI) and having the credentials that you've established during gh auth login be automatically used without your intervention.

Alternatively, we could ensure that only gh-initiated git operations (e.g. git clone within gh repo clone, git push within gh pr create) are properly authenticated, but that regular git operations that you initiate outside of gh are left intact (and possibly un-authenticated). This approach would be simpler to achieve, but I think it would be worse for the user experience, because GitHub CLI often relies on regular git operations to be combined with it during everyday workflows.

Something that I've noticed in both hub and GitHub CLI: after users log into GitHub from the command line, they expect to be logged into GitHub for all their GitHub-related operations. To meet their expectations, I think that in this case it's worth leaving the boundaries of our own tool and making sure things work for them even when they were not explicitly using our tool.

How about Authenticate Git with your GitHub credentials?

Since GitHub CLI now offers to authenticate your Git as well, the token we request here will be used for git pushes. Since we do anticipate our users making edits to their GitHub Actions workflow files, we want them to be able to push their changes, and this scope allows that.

samcoe

This looks great to me! I left a couple comments/questions, but nothing blocking.

samcoe · 2020-12-10T17:01:36Z

pkg/cmd/auth/gitcredential/helper.go

+	cmd := &cobra.Command{
+		Use:    "git-credential",
+		Args:   cobra.ExactArgs(1),
+		Short:  "Implements git credential helper protocol",


Are we worried at all about this protocol updating and us having to maintain/upkeep this implementation?

The oldest reference to this specific format of the git credential protocol that I could find is from 2012, and it hasn't changed since. It's also very unlikely that git will ever change it—at least not in a backwards-incompatible way—because it's in git's strong interest to avoid breaking current programs that have implemented the protocol.

samcoe · 2020-12-10T17:17:12Z

pkg/cmd/auth/gitcredential/helper.go

+func helperRun(opts *CredentialOptions) error {
+	if opts.Operation == "store" {
+		// We pretend to implement the "store" operation, but do nothing since we already have a cached token.
+		return cmdutil.SilentError


Rather than a silent error here is it possible to send back a response saying that the user should use gh auth login/refresh to do this operation? This seems like it would only be called if a user is explicitly trying set credentials from the git command, right?

For a user, that would make sense! But the user doesn't ever interact with this helper directly. Instead, git invokes it internally when git credential is interacted with, and the user typically doesn't even interact with git credential themselves. So I don't think a more helpful error would be useful here.

Furthermore, when multiple credential helpers are configured, git currently uses them in a sort of a chained sequence, taking credentials from one and storing them into all others. This is why I felt it was important to implement store, but also to discard any attempt to actually store credentials, since those unrelated to GitHub we don't want to store, and those for GitHub we already have.

neilalb16

restore

mislav added 3 commits November 20, 2020 19:36

Prime user's git HTTPS credentials on auth login

67672fa

Avoid re-requesting username if we already have it

91d2adc

Fix broken tests

e36c902

If git credential helper is non-defined, set gh as credential helper

d56d92c

vilmibm reviewed Nov 23, 2020

View reviewed changes

billygriffin reviewed Nov 23, 2020

View reviewed changes

mislav added 5 commits December 7, 2020 17:08

Rename auth/client to auth/shared

c39dc28

Extend git credential prompt to auth refresh

381e83e

Add tests for auth git-credential command

3c76eb1

Merge remote-tracking branch 'origin' into git-credentials

bc81282

Fix refresh test

38ea595

mislav marked this pull request as ready for review December 7, 2020 19:07

mislav requested review from samcoe and vilmibm December 7, 2020 19:08

samcoe approved these changes Dec 10, 2020

View reviewed changes

mislav merged commit b1f9342 into trunk Dec 15, 2020

mislav deleted the git-credentials branch December 15, 2020 15:14

mislav mentioned this pull request Feb 10, 2021

Internal git pull/push operations are not always authenticated #2944

Closed

3 tasks

mislav mentioned this pull request Feb 18, 2021

Git credential helper error with Homebrew #2995

Closed

mislav mentioned this pull request Mar 2, 2021

Allow gh auth git-credential to authenticate GitHub Gist requests #3064

Merged

1 task

gibfahn mentioned this pull request Apr 12, 2021

feat(download_strategy): allow using netrc auth in curl strategies Homebrew/brew#11091

Closed

gibfahn mentioned this pull request Oct 1, 2021

Provide a convenient way to add gh cli as a git credential helper #3796

Closed

aidan-melen mentioned this pull request Feb 24, 2022

use gh auth git-credential codespaces-contrib/codespaces-multi-repo#1

Open

ijlyttle mentioned this pull request May 1, 2023

VSCode not picking up on git credential helper microsoft/vscode-tools-for-ai#2020

Closed

neilalb16 reviewed Jan 5, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Set up git authentication when logging in to gh#2449

Set up git authentication when logging in to gh#2449
mislav merged 10 commits intotrunkfrom
git-credentials

mislav commented Nov 20, 2020 •

edited

Loading

Uh oh!

ampinsk commented Nov 23, 2020

Uh oh!

mislav commented Nov 23, 2020 •

edited

Loading

Uh oh!

vilmibm left a comment

Uh oh!

billygriffin Nov 23, 2020

Uh oh!

mislav Nov 24, 2020 •

edited

Loading

Uh oh!

ampinsk Nov 24, 2020

Uh oh!

samcoe left a comment

Uh oh!

samcoe Dec 10, 2020

Uh oh!

mislav Dec 14, 2020

Uh oh!

samcoe Dec 10, 2020

Uh oh!

mislav Dec 14, 2020

Uh oh!

neilalb16 left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

	Message: "Set up git for passwordless push/pull operations?",
	Message: "Also set up Git authentication for GitHub CLI operations that leverage Git?",

Conversation

mislav commented Nov 20, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ampinsk commented Nov 23, 2020

Uh oh!

mislav commented Nov 23, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vilmibm left a comment

Choose a reason for hiding this comment

Uh oh!

billygriffin Nov 23, 2020

Choose a reason for hiding this comment

Uh oh!

mislav Nov 24, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ampinsk Nov 24, 2020

Choose a reason for hiding this comment

Uh oh!

samcoe left a comment

Choose a reason for hiding this comment

Uh oh!

samcoe Dec 10, 2020

Choose a reason for hiding this comment

Uh oh!

mislav Dec 14, 2020

Choose a reason for hiding this comment

Uh oh!

samcoe Dec 10, 2020

Choose a reason for hiding this comment

Uh oh!

mislav Dec 14, 2020

Choose a reason for hiding this comment

Uh oh!

neilalb16 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

mislav commented Nov 20, 2020 •

edited

Loading

mislav commented Nov 23, 2020 •

edited

Loading

mislav Nov 24, 2020 •

edited

Loading