On 2023-02-01 03:24, Jeff King wrote: > On Fri, Jan 27, 2023 at 09:06:36AM -0800, Junio C Hamano wrote: > >> Rick van Rein <rick@xxxxxxxxxxxxxxx> writes: >> >>> Git providers are inventing proprietary extensions to HTTP authentication >>> for Git. It seems smarter to use SASL for this purpose, possibly allowing >>> the client a choice and authentication ringback to the client's own domain. >> >> To adopt things like this, the work to extend how to make extensible >> what is on WWW-Authenticate in the thread that contains this recent >> message https://lore.kernel.org/git/Y9LvFMzriAWUsS58@xxxxxxxxxxxxxxxxxxxxxxx/ >> may be relevant, perhaps? > > It's relevant, but I think there's a ways to go. That is just about > passing WWW-Authenticate headers to helpers, which can then try to make > sense of them. But Git would still only understand getting back a > username/password from the helper, and passing it along to curl. And > hopefully we'd do it all through curl's SASL support, and not invent our > own handling. > > I'm not sure what all that might might look like. I'm sure Matthew has > probably thought about it, so I'll let him say something more > intelligent. :) > > -Peff These are the same thoughts I have on this. My patches only add support for the Git -> helper information flow, but don't make an attempt to change how helpers can change Git's (curl's) response or behaviour. I had earlier iterations [1] of the patch that included the ability to change the auth type/headers that curl would respond with based on the helper's output. For example: protocol=https host=example.com password=<TOKEN> authtype=bearer ..would have Git configure curl to set CURLOPT_XOAUTH2_BEARER. However I pulled these patches to keep the scope of that series smaller. It's still my plan to reintroduce such a patch series in the future. I'd imagine that Git could advertise to helpers that its version of curl supports SASL and a helper could enable or select this mechanism. Alternatively it could just be a Git config to enable it outright `credential.useSasl` or something. I haven't had chance to review SASL yet. Thanks, Matthew [1] https://lore.kernel.org/git/230118.86k01kxfr7.gmgdl@xxxxxxxxxxxxxxxxxxx/T/#m37fffe327593ca4f7bf32a205b7ee1d1ecd1ed46