Repository navigation
feat: Support for storing OAuth token in encrypted keychain #449
Description
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.
Reacted by Mislav Marohnić, Peter Šándor, Jacek Suliga, djr7C4, Yutaro Muta, Matthew Cline, Nirojan Vythilingam, Patrick Hoefler, emlimap, Tamás Demeter-Haludka and 11 more
Reacted by Oliver Mannion
Reacted by Oliver Mannion
Activity
jasonkarns commentedon Feb 25, 2020
semi-related to #288
mislav commentedon Feb 28, 2020
We were eyeing https://github.com/zalando/go-keyring as a potential library to store OAuth in an OS-specific keychain app.
mislav commentedon May 27, 2020
Some notes about more storage mechanisms:
jmkk commentedon Oct 12, 2020
On Enterprise side, we'd like to +1 this ask.
djr7C4 commentedon Oct 19, 2020
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)"dsseng commentedon Dec 26, 2020
https://github.com/99designs/keyring library looks applicable for this. It's platform-agnostic.
rzhade3 commentedon Dec 3, 2021
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.evgeny-roubinchtein commentedon Mar 22, 2022
Alternatively, 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...
kieranparsons commentedon Jan 25, 2023
Firstly, 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.
mislav commentedon Jan 25, 2023
@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.
mislav commentedon Jan 26, 2023
We'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.
mbainter commentedon Feb 15, 2023
The 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.reegnz commentedon Feb 21, 2023
I 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.