Show HN: Git credential helper using OAuth in browser | Hacker News Reader

Show HN: Git credential helper using OAuth in browser

73 pointsmattme18 comments

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.

View on HN

Why is GCM hard to install on Linux? .NET can cross compile a self contained, single file binary for Linux, much like Go can.

.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-...

There seems to be a discussion at https://github.com/dotnet/source-build/discussions/2960

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?

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

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.

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.

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!

Thanks! Homebrew formula in review https://github.com/Homebrew/homebrew-core/pull/132580

GCM (which I guess inspired this) is already available via Homebrew https://github.com/git-ecosystem/git-credential-manager/blob...

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)

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.

> 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).

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....

Thank you. This behavior isn't documented in the man pages as far as I can tell?

Suprisingly calling "man git add" will also look for a manpage call "git-add" and display it.

Apparently, not. Side note, kubectl also has this feature with similar convention wrt binary name pattern.

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.

Reply on news.ycombinator.com