From: ken.fuchs@bench.com Date: Wed, 27 Feb 2008 22:10:57 GMT Subject: RE: FW: git via http protocol _and_ a proxy using NTLMauthentication -- git 1.5.4.2 & curl 7.18.0 Message-ID: > Ken Fuchs wrote: Current changes to http.c, get_curl_handle() and transport.c, get_refs_via_curl(): > > + curl_easy_setopt(slot->curl, CURLOPT_PROXYAUTH, > > (long)CURLAUTH_NTLM); > > + curl_easy_setopt(slot->curl, CURLOPT_PROXYUSERPWD, > > ":"); Mike Hommey wrote: > Starting with curl 7.14.1, you're supposed to be able to use the > http://user:pass@proxy/ syntax, though I'm not sure it deals well with > NTLM domains. You can probably leave CURLOPT_PROXYUSERPWD out if you > set your proxy url correctly. Leaving out the line above containing CURLOPT_PROXYUSERPWD in both http.c and transport.c and using curl 7.18.0 ... $ http_proxy=user-id:password@proxy.domain: GIT_CURL_VERBOSE=1 \ git fetch http://www.kernel.org/pub/scm/git/git.git fails proxy NTLM authentication. The correct user-id is used, but maybe the password wasn't correctly parsed. > As for CURLOPT_PROXYAUTH, it would be better to set it from another > config. From a later message: > Or we should set it to CURLOPT_AUTHANY by default. The code should probably do both. > > * Connection #0 to host left intact > > fatal: Couldn't find remote ref HEAD > > > > So, the proxy communication via NTLM authentication seems > > to be working. > > The patch to transport.c did not change anything as far as > > I can see. > > > > The fatal error is from remote.c. Perhaps, it also requires some > > changes. > > Does your remote have a HEAD ref ? The command used to generate the above output is: $ GIT_CURL_VERBOSE=1 git fetch \ http://www.kernel.org/pub/scm/git/git.git I originally tried the following command as suggested by the git home page for getting "git by git". $ GIT_CURL_VERBOSE=1 git clone \ http://www.kernel.org/pub/scm/git/git.git Initialized empty Git repository in /mnt/s2u1/git/test-git/git/.git/ Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? $ This seemed like a good test for validating my git installation, but this command doesn't access the proxy at all. The fetch command does. Why the difference? Thanks, Ken Fuchs