| Message ID | pull.1538.git.1685303127237.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | doc: gitcredentials: introduce OAuth helpers | expand |
On 2023-05-28 at 19:45:27, M Hickford via GitGitGadget wrote: > From: M Hickford <mirth.hickford@gmail.com> > > OAuth credential helpers are widely useful but work differently to other > credential helpers, so worth introducing in the docs. > > Link to relevant projects. There are many possible implementations of credential helpers, and I'd prefer we didn't specifically propose any of them here. We ship with some in contrib, and I think it would be better to fix them to be functional for this use case rather than link to external projects. I expect, however, that functionally, that will be difficult to do, given the fact that OAuth typically requires registration with the remote system, and thus we'd intrinsically be prioritizing some well-known forges over less-known or personally-hosted forges, which we've traditionally tried not to do. For example, your git-credential-oauth contains a hard-coded list of 11 forges (and also proposes adding credentials for new ones into the config, which isn't really a secure way to store secrets).
On Sun, 28 May 2023 at 23:51, brian m. carlson <sandals@crustytoothpaste.net> wrote: > > On 2023-05-28 at 19:45:27, M Hickford via GitGitGadget wrote: > > From: M Hickford <mirth.hickford@gmail.com> > > > > OAuth credential helpers are widely useful but work differently to other > > credential helpers, so worth introducing in the docs. > > > > Link to relevant projects. > > There are many possible implementations of credential helpers, and I'd > prefer we didn't specifically propose any of them here. We ship with > some in contrib, and I think it would be better to fix them to be > functional for this use case rather than link to external projects. Thanks Brian for your reply. I'd love to upstream OAuth functionality in Git, but I think it'd be prohibitively difficult technically without introducing extra dependencies. git-credential-oauth is little more than 100 lines of Go, but it takes advantage of Go's broad standard library and a library for OAuth. I expect that would require tens of thousands of lines of challenging C. https://github.com/hickford/git-credential-oauth/issues/8 I think OAuth is such a boon for usable security that it's worth describing and linking to external projects. The text aims to inform the user rather than tell them to use a particular project. An alternative would be to link to a new 'credential helpers' page on git-scm.com > > I expect, however, that functionally, that will be difficult to do, > given the fact that OAuth typically requires registration with the > remote system, and thus we'd intrinsically be prioritizing some > well-known forges over less-known or personally-hosted forges, which > we've traditionally tried not to do. For example, your In that spirit, the patch avoids naming "popular Git hosts". > git-credential-oauth contains a hard-coded list of 11 forges (and also > proposes adding credentials for new ones into the config, which isn't > really a secure way to store secrets). To clarify, it's expected that client credentials in OAuth native apps (unlike web apps) are non-confidential. "It is assumed that any client authentication credentials included in the application can be extracted" https://datatracker.ietf.org/doc/html/rfc6749#section-2.1 > -- > brian m. carlson (he/him or they/them) > Toronto, Ontario, CA
> I expect, however, that functionally, that will be difficult to do, > given the fact that OAuth typically requires registration with the > remote system, and thus we'd intrinsically be prioritizing some > well-known forges over less-known or personally-hosted forges, which > we've traditionally tried not to do. For example, your > git-credential-oauth contains a hard-coded list of 11 forges Forge diversity is my motivation! Consider the average Git user. They contribute to several projects on GitHub. They are deterred from contributing to worthy projects elsewhere by the setup cost of configuring personal access tokens or SSH keys. To use five forges from three machines, you have to generate 15 personal access tokens or upload SSH keys 15 times. Whereas a git-credential-oauth user can contribute to projects on many popular hosts without any setup. That's progress surely.
diff --git a/Documentation/gitcredentials.txt b/Documentation/gitcredentials.txt index 100f045bb1a..d2a7249d52b 100644 --- a/Documentation/gitcredentials.txt +++ b/Documentation/gitcredentials.txt @@ -105,6 +105,19 @@ $ git config --global credential.helper foo ------------------------------------------- +=== OAuth credential helpers + +An alternative to entering passwords or personal access tokens is to use an +OAuth credential helper. Many popular Git hosts support OAuth. The first time +you authenticate, the helper opens a browser window to the host. +Subsequent authentication is non interactive. + +Two cross-platform open-source OAuth credential helpers are: + +* https://github.com/git-ecosystem/git-credential-manager[Git Credential Manager] +* https://github.com/hickford/git-credential-oauth[git-credential-oauth] + + CREDENTIAL CONTEXTS -------------------