On Tue, Oct 21, 2008 at 01:44:53PM -0700, Dan Fandrich wrote:

Thanks for the fast response, Dan!

> On Tue, Oct 21, 2008 at 09:13:09PM +0200, Josef Wolf wrote:
> > First question is: what is the default place where curl searches for
> > CA certificates? I have to explicitly use the --cacert or the --capath
> > options if I want to use the certificates that come with openssl.
>
> This is determined at compile time. The curl configure script tries to make
> an intelligent guess but it's sometimes wrong. It's up to the package
> maintainer to make sure that curl is compiled with a correct path. It
> sounds like your package is broken

OK, I'll check that. But this is a minor problem, because it can be
configured statically once and forever.

> > $ curl https://test.host/git/test1/HEAD
> > [ 401 error ]
> > $ curl https://user@test.host/git/test1/HEAD
> > [ 401 error ]
>
> In this case you specify a user name but no password, so curl sends a
> user name and no password to the host.

Yes, I see. The problem is that this breaks the challenge-response
mechanism described in rfc2617.

> > $ curl --user user https://test.host/git/test1/HEAD
> > Enter host password for user 'user':
> > [ works ]
> >
> > Curl asks me for a password and retrieves the file only if I supply
> > the --user option.
>
> That's by design.

Hmm, what is the fundamental difference that causes curl to ask for
password in one case but not in the two cases above? Is there a
rationale for handling it this way? Are the other authentication
mechanisms handled in the same way?

> > First problem is, prefixing user in front of hostname don't work.
> > IMHO, this is a bug in curl, since this format is explicitly documented.
>
> It does work, just not in the way you expect.

Well, I see that my expectation does not match reality ;-) So I'm
trying to find out what's wrong with my expectation :) What I am
trying to achieve is pretty straight forward: when a git command
stumbles over a 401, I'd like to be asked for credentials for the
appropriate realm. And I do _not_ want to store passwords in
some clear text files

If I look at any other user agent, I see that they all work by
querying the user (or a credential cache) whenever a 401 is
received.
 
> curl assumes that a user
> name & password specified in a URL is complete and doesn't request a
> further password from the user in this case.

IMHO, this is very impractical: often URLs are specified on command
line, revealing the password to everyone who can run ps.

> > Next, I try to find out how to use libcurl so that it asks me for a
> > password:
>
> libcurl doesn't ask for a password--curl asks for the password and sends
> it to libcurl. If you want to replicate that functionality in your own
> application, you'll have to read a password from the user yourself.

So to mimic the behavior of a web browser, the application (git in this
case) should be able to recognize the 401, find out the realm, and
finally repeat the request.
Received on 2008-10-22