forcing a user@ into the URL if not present

forcing a user@ into the URL if not present

[Dan Langille]

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.

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

[Dan Langille]

Would this question be better suited for another list?

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?
>
> 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.

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]

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.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Dan Langille]

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.

>> 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.

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

[Dan Langille]

On Mon, May 4, 2015 at 3:35 PM, Dan Langille <dlangille@sourcefire.com> wrote:
> 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.

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

[Johannes Schindelin]

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

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

[Junio C Hamano]

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?

Thanks.

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

[Torsten Bögershausen]

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.
>
> 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.

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

[Johannes Schindelin]

Hi Torsten & Junio,

On 2015-05-06 06:52, Torsten Bögershausen wrote:
> 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.

>> 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

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

[Junio C Hamano]

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

>>> 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" ;-)

> 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.