On Sun, 28 May 2023 at 23:51, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 2023-05-28 at 19:45:27, M Hickford via GitGitGadget wrote: > > From: M Hickford <mirth.hickford@xxxxxxxxx> > > > > 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
