Re: Git over HTTP; have flexible SASL authentication

[Matthew John Cheetham <mjcheetham@github.com>]

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@openfortress.nl> 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@coredump.intra.peff.net/
>> 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@evledraar.gmail.com/T/#m37fffe327593ca4f7bf32a205b7ee1d1ecd1ed46