threads / discuss / 39141

forcing a user@ into the URL if not present

Subject: forcing a user@ into the URL if not present

## tl;dr

10 messages between Apr 22, 2015 and May 6, 2015.

replies: 9people: 5as markdown or json

Dan Langille· Apr 22, 2015, 20:06 UTC · lore
Hello,

I'm using git 2.3.2 with Kerberos for authentication and gito-lite for authorization.

This works:

$ git clone https://dvl@ repo.example.org/git/testing Cloning into 'testing'... warning: You appear to have cloned an empty repository. Checking connectivity... done.

My goal: have it work without supplying dvl@ as shown here:

$ git clone https://repo.example.org/git/testing Cloning into 'testing'... Username for 'https://repo.example.org':

I don't want to be prompted for a password.  I want Kerberos to kick in.

Following http://git-scm.com/docs/gitcredentials, the following seems to have nil effect. Anyone used this feature already?

  git config --global credential.https://repo.example.org.username dvl

$ cat ~/.gitconfig [credential "https://repo.example.org"] username = dvl [http] sslCAInfo = /usr/local/etc/trusted-certificates.pem

With the above, I still get prompted for a password
Given my use of Kerberos for authorization, is this option feasible?
Should I be taking a different approach?
Thank you.
-- 
Dan Langille
Infrastructure & Operations
Talos Group
Sourcefire, Inc.
Dan Langille· Apr 30, 2015, 20:14 UTC · re: Dan Langille · lore

Re: forcing a user@ into the URL if not present

Would this question be better suited for another list?
On Wed, Apr 22, 2015 at 4:06 PM, Dan Langille <dlangille@sourcefire.com> wrote:
Show 44 quoted lines
> Hello,
>
> I'm using git 2.3.2 with Kerberos for authentication and gito-lite for
> authorization.
>
> This works:
>
> $ git clone https://dvl@ repo.example.org/git/testing
> Cloning into 'testing'...
> warning: You appear to have cloned an empty repository.
> Checking connectivity... done.
>
> My goal: have it work without supplying dvl@ as shown here:
>
> $ git clone https://repo.example.org/git/testing
> Cloning into 'testing'...
> Username for 'https://repo.example.org':
>
> I don't want to be prompted for a password.  I want Kerberos to kick in.
>
> Following http://git-scm.com/docs/gitcredentials, the following seems to
> have nil effect.  Anyone used this feature already?
>
>   git config --global credential.https://repo.example.org.username dvl
>
> $ cat ~/.gitconfig
> [credential "https://repo.example.org"]
> username = dvl
> [http]
> sslCAInfo = /usr/local/etc/trusted-certificates.pem
>
> With the above, I still get prompted for a password
>
> Given my use of Kerberos for authorization, is this option feasible?
>
> Should I be taking a different approach?
>
> Thank you.
>
> --
> Dan Langille
> Infrastructure & Operations
> Talos Group
> Sourcefire, Inc.
-- 
Dan Langille
Infrastructure & Operations
Talos Group
Sourcefire, Inc.
brian m. carlson· Apr 30, 2015, 20:23 UTC · re: Dan Langille · lore

Re: forcing a user@ into the URL if not present

On Thu, Apr 30, 2015 at 04:14:12PM -0400, Dan Langille wrote:
> Would this question be better suited for another list?
Nope, this is the place to go.
Show 35 quoted lines
> On Wed, Apr 22, 2015 at 4:06 PM, Dan Langille <dlangille@sourcefire.com> wrote:
> > Hello,
> >
> > I'm using git 2.3.2 with Kerberos for authentication and gito-lite for
> > authorization.
> >
> > This works:
> >
> > $ git clone https://dvl@ repo.example.org/git/testing
> > Cloning into 'testing'...
> > warning: You appear to have cloned an empty repository.
> > Checking connectivity... done.
> >
> > My goal: have it work without supplying dvl@ as shown here:
> >
> > $ git clone https://repo.example.org/git/testing
> > Cloning into 'testing'...
> > Username for 'https://repo.example.org':
> >
> > I don't want to be prompted for a password.  I want Kerberos to kick in.
> >
> > Following http://git-scm.com/docs/gitcredentials, the following seems to
> > have nil effect.  Anyone used this feature already?
> >
> >   git config --global credential.https://repo.example.org.username dvl
> >
> > $ cat ~/.gitconfig
> > [credential "https://repo.example.org"]
> > username = dvl
> > [http]
> > sslCAInfo = /usr/local/etc/trusted-certificates.pem
> >
> > With the above, I still get prompted for a password
> >
> > Given my use of Kerberos for authorization, is this option feasible?

Not at the present time. The only time that the credential API is invoked is if it prompts for a password, and by that point you've fallen back to Basic authentication.

> > Should I be taking a different approach?

If you want it to work only with Kerberos, then any username in the URL is fine, as libcurl doesn't care.

One thing you could try is to make your URL https://git@repo.example.org and then use

  git config --global credential.https://git@repo.example.org.username dvl

and see if it does the right thing for both Kerberos and Basic auth. It would be sort of a hack, but it might work.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Dan Langille· May 4, 2015, 19:35 UTC · re: brian m. carlson · lore

Re: forcing a user@ into the URL if not present

On Thu, Apr 30, 2015 at 4:23 PM, brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 49 quoted lines
> On Thu, Apr 30, 2015 at 04:14:12PM -0400, Dan Langille wrote:
>> Would this question be better suited for another list?
>
> Nope, this is the place to go.
>
>> On Wed, Apr 22, 2015 at 4:06 PM, Dan Langille <dlangille@sourcefire.com> wrote:
>> > Hello,
>> >
>> > I'm using git 2.3.2 with Kerberos for authentication and gito-lite for
>> > authorization.
>> >
>> > This works:
>> >
>> > $ git clone https://dvl@ repo.example.org/git/testing
>> > Cloning into 'testing'...
>> > warning: You appear to have cloned an empty repository.
>> > Checking connectivity... done.
>> >
>> > My goal: have it work without supplying dvl@ as shown here:
>> >
>> > $ git clone https://repo.example.org/git/testing
>> > Cloning into 'testing'...
>> > Username for 'https://repo.example.org':
>> >
>> > I don't want to be prompted for a password.  I want Kerberos to kick in.
>> >
>> > Following http://git-scm.com/docs/gitcredentials, the following seems to
>> > have nil effect.  Anyone used this feature already?
>> >
>> >   git config --global credential.https://repo.example.org.username dvl
>> >
>> > $ cat ~/.gitconfig
>> > [credential "https://repo.example.org"]
>> > username = dvl
>> > [http]
>> > sslCAInfo = /usr/local/etc/trusted-certificates.pem
>> >
>> > With the above, I still get prompted for a password
>> >
>> > Given my use of Kerberos for authorization, is this option feasible?
>
> Not at the present time.  The only time that the credential API is
> invoked is if it prompts for a password, and by that point you've fallen
> back to Basic authentication.
>
>> > Should I be taking a different approach?
>
> If you want it to work only with Kerberos, then any username in the URL
> is fine, as libcurl doesn't care.

That is what I found during testing. So long as I put a username in the URL, Kerberos worked and all authentication occurred as expected.

Show 7 quoted lines
>> One thing you could try is to make your URL https://git@repo.example.org
> and then use
>
>   git config --global credential.https://git@repo.example.org.username dvl
>
> and see if it does the right thing for both Kerberos and Basic auth.  It
> would be sort of a hack, but it might work.
It asks for a password, and for the correct user:
Password for 'https://dvl@repo.example.org':
Thanks Brian, for this, and your other help.  I appreciate it.
-- 
Dan Langille
Infrastructure & Operations
Talos Group
Sourcefire, Inc.
Dan Langille· May 5, 2015, 12:35 UTC · re: Dan Langille · lore

Re: forcing a user@ into the URL if not present

On Mon, May 4, 2015 at 3:35 PM, Dan Langille <dlangille@sourcefire.com> wrote:
Show 55 quoted lines
> On Thu, Apr 30, 2015 at 4:23 PM, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
>> On Thu, Apr 30, 2015 at 04:14:12PM -0400, Dan Langille wrote:
>>> Would this question be better suited for another list?
>>
>> Nope, this is the place to go.
>>
>>> On Wed, Apr 22, 2015 at 4:06 PM, Dan Langille <dlangille@sourcefire.com> wrote:
>>> > Hello,
>>> >
>>> > I'm using git 2.3.2 with Kerberos for authentication and gito-lite for
>>> > authorization.
>>> >
>>> > This works:
>>> >
>>> > $ git clone https://dvl@ repo.example.org/git/testing
>>> > Cloning into 'testing'...
>>> > warning: You appear to have cloned an empty repository.
>>> > Checking connectivity... done.
>>> >
>>> > My goal: have it work without supplying dvl@ as shown here:
>>> >
>>> > $ git clone https://repo.example.org/git/testing
>>> > Cloning into 'testing'...
>>> > Username for 'https://repo.example.org':
>>> >
>>> > I don't want to be prompted for a password.  I want Kerberos to kick in.
>>> >
>>> > Following http://git-scm.com/docs/gitcredentials, the following seems to
>>> > have nil effect.  Anyone used this feature already?
>>> >
>>> >   git config --global credential.https://repo.example.org.username dvl
>>> >
>>> > $ cat ~/.gitconfig
>>> > [credential "https://repo.example.org"]
>>> > username = dvl
>>> > [http]
>>> > sslCAInfo = /usr/local/etc/trusted-certificates.pem
>>> >
>>> > With the above, I still get prompted for a password
>>> >
>>> > Given my use of Kerberos for authorization, is this option feasible?
>>
>> Not at the present time.  The only time that the credential API is
>> invoked is if it prompts for a password, and by that point you've fallen
>> back to Basic authentication.
>>
>>> > Should I be taking a different approach?
>>
>> If you want it to work only with Kerberos, then any username in the URL
>> is fine, as libcurl doesn't care.
>
> That is what I found during testing.  So long as I put a username in
> the URL, Kerberos worked
> and all authentication occurred as expected.

As I understand it, in order to invoke Kerberos Authentication, a username must be in the URL, but that username is not involved in the authentication process. Thus, the username in the config is never applied to any URL and does not not work the same way as a username which appears in the URL.

I suspect this is because a username in the URL invokes authentication, which prompts the whole Kerberos process.

The best workaround I've found is this configuration item:
[url "https://FOO@repo.example.org"]
        insteadOf = https://repo.example.org

We'd be happy if we could set this as a global config setting and not have the users prompted for a password. The whole beauty of Kerberos is not getting prompted for stuff. Am I simply failing to comprehend the steps involved in Kerberos Authentication?

What bits of code would need looking at in order for git authentication to work seamlessly with Kerberos? We are so close.

-- 
Dan Langille
Infrastructure & Operations
Talos Group
Sourcefire, Inc.
Johannes Schindelin· May 5, 2015, 13:59 UTC · re: Dan Langille · lore

Re: forcing a user@ into the URL if not present

Hi Dan,
On 2015-05-05 14:35, Dan Langille wrote:
> As I understand it, in order to invoke Kerberos Authentication, a
> username must be in the URL, but that username is not involved in the
> authentication process.
Having stumbled over [this ticket](https://github.com/git-for-windows/git/issues/92) recently, it appears to me as if the following should work for you:
git clone https://:@repo.example.org/

Ciao, Johannes

Junio C Hamano· May 5, 2015, 17:45 UTC · re: Johannes Schindelin · lore

Re: forcing a user@ into the URL if not present

Johannes Schindelin <johannes.schindelin@gmx.de> writes:
Show 5 quoted lines
> Having stumbled over [this
> ticket](https://github.com/git-for-windows/git/issues/92) recently, it
> appears to me as if the following should work for you:
>
> git clone https://:@repo.example.org/
Wow.

Is this a windows-only SSPI thing, or is this a widely accepted URL convention? I haven't seen anybody use such a URL but I would say that is a natural thing to expect to work, as both username and password are missing so they should default to some sensible values, in this case "current user, shouldn't need password", just like "scheme://site:/" is "port missing so it should default to some sensible value, appropriate for the scheme".

I think Torsten recently added a bit more test for our URL parsing code, especially for "scheme://site:/" (missing port), but I do not think we have "scheme://:site/" (missing user or password). Perhaps we would want to have additional tests to cover this shape of URL?

Thanks.
Torsten Bögershausen· May 6, 2015, 04:52 UTC · re: Junio C Hamano · lore

Re: forcing a user@ into the URL if not present

On 05/05/2015 07:45 PM, Junio C Hamano wrote:
Show 22 quoted lines
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
>> Having stumbled over [this
>> ticket](https://github.com/git-for-windows/git/issues/92) recently, it
>> appears to me as if the following should work for you:
>>
>> git clone https://:@repo.example.org/
> Wow.
>
> Is this a windows-only SSPI thing, or is this a widely accepted URL
> convention?  I haven't seen anybody use such a URL but I would say
> that is a natural thing to expect to work, as both username and
> password are missing so they should default to some sensible values,
> in this case "current user, shouldn't need password", just like
> "scheme://site:/" is "port missing so it should default to some
> sensible value, appropriate for the scheme".
>
> I think Torsten recently added a bit more test for our URL parsing
> code, especially for "scheme://site:/" (missing port), but I do not
> think we have "scheme://:site/" (missing user or password).  Perhaps
> we would want to have additional tests to cover this shape of URL?
>

I have added tests for URL parsing, but for host names/port numbers. Not for usernames/passwords (passwords shouldn't be there, recommends RFC 3986)

And only for the ssh:// protocol, as well as git://. http:// and https:// are not handled by connect.c at all, and I'm not really familiar with curl, nor kerberos.

In other words: I can not help very much at the moment.
Johannes Schindelin· May 6, 2015, 05:29 UTC · re: Torsten Bögershausen · lore

Re: forcing a user@ into the URL if not present

Hi Torsten & Junio,
On 2015-05-06 06:52, Torsten Bögershausen wrote:
Show 10 quoted lines
> On 05/05/2015 07:45 PM, Junio C Hamano wrote:
>> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>>
>>> Having stumbled over [this
>>> ticket](https://github.com/git-for-windows/git/issues/92) recently, it
>>> appears to me as if the following should work for you:
>>>
>>> git clone https://:@repo.example.org/
>>
>> Wow.
My reaction exactly.
>> Is this a windows-only SSPI thing, or is this a widely accepted URL convention?
Quite frankly, I have no idea. Before reading that ticket, I did not even think of trying such a convention.
>> I haven't seen anybody use such a URL but I would say that is a natural thing to expect to work, as both username and password are missing so they should default to some sensible values, in this case "current user, shouldn't need password", just like "scheme://site:/" is "port missing so it should default to some sensible value, appropriate for the scheme".
Yes, that makes total sense to me, too. In fact, I found it rather clever once I got over the surprise.
Show 12 quoted lines
>> I think Torsten recently added a bit more test for our URL parsing
>> code, especially for "scheme://site:/" (missing port), but I do not
>> think we have "scheme://:site/" (missing user or password).  Perhaps
>> we would want to have additional tests to cover this shape of URL?
>>
> I have added tests for URL parsing, but for host names/port numbers.
> Not for usernames/passwords (passwords shouldn't be there,
> recommends RFC 3986)
> 
> And only for the ssh:// protocol, as well as git://.
> http:// and https:// are not handled by connect.c at all,
> and I'm not really familiar with curl, nor kerberos.
TBH it does not seem overly urgent to add those tests for the HTTPS handling. From a cursory look it seems that neither `transport_helper_init()` nor any code in `remote-curl.c` parses the "<user@password>" part of the URL, or for that matter puts restrictions on it. The issue I linked to was with a cURL that was compiled without support for the particular authentication method configured for the credential helper.
So I fear that testing the KERBEROS support would be the duty of an integration test (which we do not have so far) rather than a unit test.

Ciao, Dscho

Junio C Hamano· May 6, 2015, 17:18 UTC · re: Johannes Schindelin · lore

Re: forcing a user@ into the URL if not present

Johannes Schindelin <johannes.schindelin@gmx.de> writes:
Show 9 quoted lines
>>> I haven't seen anybody use such a URL but I would say that is a
>>> natural thing to expect to work, as both username and password are
>>> missing so they should default to some sensible values, in this
>>> case "current user, shouldn't need password", just like
>>> "scheme://site:/" is "port missing so it should default to some
>>> sensible value, appropriate for the scheme".
>
> Yes, that makes total sense to me, too. In fact, I found it rather
> clever once I got over the surprise.
Yup, I'd happily call that "clever" ;-)
Show 5 quoted lines
> TBH it does not seem overly urgent to add those tests for the HTTPS
> handling. From a cursory look it seems that neither
> transport_helper_init()` nor any code in `remote-curl.c` parses the
> "<user@password>" part of the URL, or for that matter puts
> restrictions on it.
Thanks for checking.

← back to recent threads