Repository navigation
Add support for .netrc #288
Description
Describe the feature or problem you’d like to solve
A clear and concise description of what the feature or problem is.
probably more of a question than request to start with since i haven't yet had a chance to check out many details yet, but thought it would get this question on the list early.
since curl can use credentials, including tokens, configured in a ~/.netrc file, i have the github api already configured there. also, git uses curl under the hood, so credentials there can be used through git as well.
if credentials exist there, can they be used for gh as well?
Proposed solution
How will it benefit CLI and its users?
those that already have credentials configured for curl or git using a ~/.netrc could avoid configuring auth again for gh
Activity
[-].netrc support[/-][+]Add support for .netrc[/+]narqo commentedon Feb 3, 2020
Can this be extended to "Support for secure credential storage"?
Storing an OAuth token in a plain-text file feels like a potential security issue for a user. That might be an issue for the official GitHub client, as the expectations about the security for an average user are higher than from a "random tool on the internet". I propose starting the discussion on the integration of the OS's credential storages (keychain on macOS, for example).
docker/docker-credential-helpers can be looked at as the starting point.
tierninho commentedon Feb 4, 2020
Adding this comment from another thread addressing this request:
narqo commentedon Feb 4, 2020
Apparently, but not surprisingly, there are on-going discussions on the topic in
hub, where authors ofcliwere involved too mislav/hub#1217tonglil commentedon Jan 27, 2022
This is used by some CI systems to authenticate to GH.
It might be potentially insecure, but it is still a valid way of using the GH API.
adam-azarchs commentedon Mar 9, 2022
There are several cases, e.g. build systems which know how to pull dependencies over https, where being able to put the credentials in
~/.netrcwould be very useful. It's not terribly secure, but it's no worse than~/.git-credentials, whichghalready knows how to update.