Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 5, 2016, 21:02 UTC
Message-ID: <xmqqa8nedg59.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160205204648.GA7403@vauxhall.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Show 16 quoted lines

> On Fri, Feb 05, 2016 at 12:18:22PM +0300, Dmitry Vilkov wrote:
>> You are right, we are using a bare URL (without a username component).
>> With username encoded in URL everything works just fine. But it's
>> generally wrong to pass creds in URL (in my opinion) and security
>> policy of my employer prohibits doing such thing.
>> Anyway, as you said libcurl needs valid (not NULL) username/password
>> to do GSS-Negotiate, so there is nothing wrong if I set empty
>> username/password combination when git prompts for creds. Even more,
>> there is no other way to let libcurl to use GSS-Negotiate without
>> username in URL.
>
> You can literally do https://:@git.crustytoothpaste.net/git/repo.git as
> the URL, and that will work.  GSS-Negotiate using Kerberos passes the
> ticket, which contains the principal name in it, so an actual username
> and password is not needed at all.  libcurl just needs something to tell
> it to do authentication.

Hmph, so documenting that <emptyname>:<emptypassword>@<repository> as a supported way might be an ugly-looking solution to the original problem. A less ugly-looking solution might be a boolean that can be set per URL (we already have urlmatch-config infrastructure to help us do so) to tell us to pass the empty credential to lubCurl, bypassing the step to ask the user for password that we do not use.

The end-result of either of these solution would strictly be better than the patch we discussed in that the end user will not have to interact with the prompt at all, right?