HN Explorer

Show HN: Git credential helper using OAuth in browser (github.com)

73 points by mattme ↗ HN
I authenticate to many Git hosts from many machines and got tired of generating and copying personal access tokens. With credential helper git-credential-oauth, there are no personal access tokens or SSH keys to configure. Instead you authenticate in browser using OAuth.

Git Credential Manager (included with Git for Windows) has a similar feature but it's awkward for Linux users to install. git-credential-oauth is cross platform and packaged in many Linux distributions.

18 comments

[ 4.0 ms ] story [ 41.4 ms ] thread
pharmakom
Why is GCM hard to install on Linux? .NET can cross compile a self contained, single file binary for Linux, much like Go can.
mattme
.NET applications are technically challenging for Linux distributions to package because of the runtime dependency. https://github.com/dotnet/source-build/discussions/2960 .

Git Credential Manager indeed release a self-contained binary for Linux x86_64 (no arm64 yet), though the installation size is necessarily large (80 MB) to include the .NET runtime. For comparison, git-credential-oauth Linux binaries (x86_64 and arm64) are much smaller at 5 MB. https://github.com/hickford/git-credential-oauth#comparison-...

0xbadcafebee
This is amazing!!! Downloaded the Darwin arm64 release, extracted it, installed to /usr/local/bin, followed the setup instructions, cloned a Bitbucket HTTPS repo, it opened my browser and authenticated me, and the repo cloned!

We have to get this packaged in Homebrew!

cglong
GCM (which I guess inspired this) is already available via Homebrew https://github.com/git-ecosystem/git-credential-manager/blob...
0xbadcafebee
Thanks! I prefer this (git-credential-oauth) because I don't have to sign up for each service, create an oauth app, and configure the oauth plugin for each. (man, OAuth is annoying)
cglong
Oh interesting! Are you building from source or something? I admit I've never used GCM with Bitbucket, but I don't remember having to create an OAuth app for GitHub.
e12e
> Download binary (...) Then test that Git can find the application:

> git credential-oauth

> If you have problems, make sure that the binary is located in the path and is executable.

Wait, git will happily run random binaries in path?

Is there a complete list of these? I take it git credential-format-hd and git remote-format-hd will at least work?

(This is ofcourse in addition to hooks).

kroolik
Git will translate any call in the likes of `git foo bar baz` to a call to a binary `git-foo bar baz`. See https://stackoverflow.com/questions/10978257/extending-git-f....
e12e
Thank you. This behavior isn't documented in the man pages as far as I can tell?
kroolik
Apparently, not. Side note, kubectl also has this feature with similar convention wrt binary name pattern.
rjh29
Suprisingly calling "man git add" will also look for a manpage call "git-add" and display it.
0xbadcafebee
Lots of things will run random things in path... For example, some people like to use source foo in shell scripts to load another script, but that will first search PATH for foo and load it. You have to specify a "/" in foo in order to avoid the PATH search.
sluongng
Not quite sure how I feel about all the ClientSecret being hardcoded https://github.com/hickford/git-credential-oauth/blob/62635f...

Is this the only way to make OAuth credential helper work?

mathstuf
You could become a developer on each target and make your own client secrets (like I do for `rclone`, `msmtp`, and `offlineimap` access over OAuth).

OAuth makes the app authenticate as well (so that, e.g., API limits can be accounted for across all app installs). It really hampers FOSS clients because the secrets are just…there. Or you make all of your users use prebuilt binaries or become developers to get their own client credentials.

jsmith45
OAuth differentiates between public clients like this (or webpages, apps, etc), which cannot truly keep a secret, and confidential clients (like servers, or apps only installed on one person's machine) which can.

Services really are not supposed to require client secrets for public clients, because the security they can provided is super limited. Often the secret can be pretty trivially extracted just by searching for strings of the right format. The only way to provide any real security to such a secret is obfuscation, which is obviously somewhat weak.

Of course some service may just require such secrets anyway to simplify the integration instructions, which is arguably fine if the service understands that the secret is providing basically nil security for public clients.

mattme
This is expected. The OAuth spec defines two client types -- confidential clients (eg. web apps) "capable of maintaining the confidentiality of their credentials" and public clients (eg. native apps) "incapable of maintaining the confidentiality of their credentials". https://datatracker.ietf.org/doc/html/rfc6749#section-2.1

> A native application is a public client installed and executed on the device used by the resource owner ... It is assumed that any client authentication credentials included in the application can be extracted