4 ms·

Show HN: Git credential helper using OAuth in browser

73 points by mattme 3y ago

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.

pharmakom 3y ago
Why is GCM hard to install on Linux? .NET can cross compile a self contained, single file binary for Linux, much like Go can.
- milliams 3y ago
  There seems to be a discussion at https://github.com/dotnet/source-build/discussions/2960 https://github.com/dotnet/source-build/discussions/2960
- mattme 3y ago
  .NET applications are technically challenging for Linux distributions to package because of the runtime dependency. https://github.com/dotnet/source-build/discussions/2960 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-with-git-credential-manager https://github.com/hickford/git-credential-oauth#comparison-...
0xbadcafebee 3y ago
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 3y ago
  GCM (which I guess inspired this) is already available via Homebrew https://github.com/git-ecosystem/git-credential-manager/blob/release/docs/install.md#homebrew-star https://github.com/git-ecosystem/git-credential-manager/blob...
  - 0xbadcafebee 3y ago
    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 3y ago
      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.
- mattme 3y ago
  Thanks! Homebrew formula in review https://github.com/Homebrew/homebrew-core/pull/132580 https://github.com/Homebrew/homebrew-core/pull/132580
e12e 3y ago
> 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 3y ago
  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-functionality https://stackoverflow.com/questions/10978257/extending-git-f....
  - e12e 3y ago
    Thank you. This behavior isn't documented in the man pages as far as I can tell?
    - kroolik 3y ago
      Apparently, not. Side note, kubectl also has this feature with similar convention wrt binary name pattern.
    - rjh29 3y ago
      Suprisingly calling "man git add" will also look for a manpage call "git-add" and display it.
- 0xbadcafebee 3y ago
  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 3y ago
Not quite sure how I feel about all the ClientSecret being hardcoded https://github.com/hickford/git-credential-oauth/blob/62635f306e7e0bd880e93a77bdfae56aee895c3a/main.go#L44 https://github.com/hickford/git-credential-oauth/blob/62635f... Is this the only way to make OAuth credential helper work?
- mathstuf 3y ago
  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 3y ago
    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 3y ago
  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 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

73 points by mattme 3y ago

pharmakom 3y ago

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

milliams 3y ago
There seems to be a discussion at https://github.com/dotnet/source-build/discussions/2960 https://github.com/dotnet/source-build/discussions/2960
mattme 3y ago
.NET applications are technically challenging for Linux distributions to package because of the runtime dependency. https://github.com/dotnet/source-build/discussions/2960 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-with-git-credential-manager https://github.com/hickford/git-credential-oauth#comparison-...

0xbadcafebee 3y ago

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 3y ago
GCM (which I guess inspired this) is already available via Homebrew https://github.com/git-ecosystem/git-credential-manager/blob/release/docs/install.md#homebrew-star https://github.com/git-ecosystem/git-credential-manager/blob...
- 0xbadcafebee 3y ago
  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 3y ago
    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.
mattme 3y ago
Thanks! Homebrew formula in review https://github.com/Homebrew/homebrew-core/pull/132580 https://github.com/Homebrew/homebrew-core/pull/132580

e12e 3y ago

> 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 3y ago
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-functionality https://stackoverflow.com/questions/10978257/extending-git-f....
- e12e 3y ago
  Thank you. This behavior isn't documented in the man pages as far as I can tell?
  - kroolik 3y ago
    Apparently, not. Side note, kubectl also has this feature with similar convention wrt binary name pattern.
  - rjh29 3y ago
    Suprisingly calling "man git add" will also look for a manpage call "git-add" and display it.
0xbadcafebee 3y ago
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 3y ago

Not quite sure how I feel about all the ClientSecret being hardcoded https://github.com/hickford/git-credential-oauth/blob/62635f306e7e0bd880e93a77bdfae56aee895c3a/main.go#L44 https://github.com/hickford/git-credential-oauth/blob/62635f... Is this the only way to make OAuth credential helper work?

mathstuf 3y ago
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 3y ago
  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 3y ago
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 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