Repository navigation
feat: Support for storing OAuth token in encrypted keychain #449
Description
Activity
semi-related to #288
We were eyeing https://github.com/zalando/go-keyring as a potential library to store OAuth in an OS-specific keychain app.
Reacted by Tom Prince, Tim O'Guin, Carlo Cabrera and Akash GoswamiSome notes about more storage mechanisms:
Reacted by Tim O'GuinOn Enterprise side, we'd like to +1 this ask.
One way of doing this that could be nice is to use a file descriptor. This has the advantage of allowing the user to securely supply the password using any password storage application of their choice (combined with a simple shell script).
This method is used in other applications such as gpg. For example, on Linux/Unix this could look something like
gh --token-fd 3 3<<<"$(program-to-read-token-from-encrypted-password-storage)"Reacted by Tim O'Guin and Alyssa Rosshttps://github.com/99designs/keyring library looks applicable for this. It's platform-agnostic.
Reacted by Luis Marsano, Rahul Zhade and Дамјан ГеоргиевскиDouble 👍 for https://github.com/99designs/keyring,
zalando/go-keyringdoesn't use native APIs to interact with the MacOS keychain, instead opting forexec.Command()shell commands.Using the native MacOS API should be a prerequisite for the dependency we use, as that'll allow us to limit access to that credential to the GH CLI application, instead of the
securityutility.Reacted by Дамјан Георгиевски, Zoltán Reegn and Oliver MannionAlternatively, have you considered copying whatever docker-credential-helpers do? Looks like they have at least one way to make it work on every major platform...
Reacted by Bruno Bigras and AriESQFirstly, thanks for all your great work on gh - it's very useful to many people.
Is there any update on the status of this feature request? Particularly for enterprise use, this is a very important feature as plain text credential storage (even in limited access files) is a major security concern, eg see the warning under https://github.com/GitCredentialManager/git-credential-manager/blob/release/docs/credstores.md#plaintext-files.
This seems extra important since gh can also be used as a credential manager, which (as I understand it) means that the default encrypted methods on Mac (keychain) and Windows (GCM) would be replaced with a less secure method.
Reacted by Robert Phair@kieranparsons No update so far, sorry, but we've prioritized this work going into this calendar year and we're going to focus on it soon.
Reacted by Kieran Parsons, Tim O'Guin and Josh JohanningReacted by Carlo Cabrera, Tim O'Guin and Josh JohanningWe're aiming for a prototype of encrypted storage functionality around mid-February.
In the meantime, 1Password users can follow these instructions to store CLI authentication in the 1Password vault.
Reacted by Tim O'Guin, Robert Phair and Josh JohanningReacted by Tim O'Guin, Josh Johanning and Sven GrebReacted by Josh JohanningThe 1password option is nice to have, but it doesn't have any support at all for the useHttpPath flag, so you cannot leverage the newer fine-grained access tokens that are available now based on that data.
For anyone that needs this today, you can somewhat work around this by using op:// URLs in GITHUB_TOKEN with direnv (or similar env var manager), and then alias gh to
op run -- ghas specified in the plugin.Reacted by Oliver MannionI was entertaining the idea of writing something like the 1password op alias, but utilizing 99designs/keyring instead of 1password, but only a subset of the features can be covered with that approach, switching between github.com and a github enterprise with the same config is a PITA.
There are some commands like
gh repo sync [target] --source [source]where you need two tokens, so the env var route is not even an option.You essentially have to reimplement command parsing to recognize when a flag overriding the default host is given, (eg. --hostname, or --repo), or parse the current directory repo remote to determine which key to set in an env var.
Not saying it's impossible, but even the
opcli option fails to do those.I think this needs a
ghnative solution, the workarounds are incomplete.
Describe the feature or problem you’d like to solve
Support encrypted keychains for Linux, Mac, and Windows.
Proposed solution
Instead of storing the CLI application's OAuth token in plaintext, integrate with keychain applications so it stays encrypted.
Additional context
aws-vault uses its own library for interacting with the various keychain applications.
aws-okta also implements the same library to store credentials for both Okta sessions and AWS role sessions.