http.c (curl_easy_setopt and CURLAUTH_ANY)

http.c (curl_easy_setopt and CURLAUTH_ANY)

[Stephen Kazakoff]

Hi,

When I'm behind a proxy (with BASIC authentication), I'm unable to
perform a git clone.

I managed to fix this by editing http.c and recompiling. The change
I'd like to propose is to line 452.


From:

curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);

To:

curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_BASIC | CURLAUTH_NTLM);


I did however find the CURL documentation
(https://secure.php.net/manual/en/function.curl-setopt.php) slightly
conflicting. On one hand, "CURLAUTH_ANY" is effectively the same as
passing "CURLAUTH_BASIC | CURLAUTH_NTLM". But the documentation for
"CURLOPT_PROXYAUTH" says that only "CURLAUTH_BASIC" and
"CURLAUTH_NTLM" are currently supported. By that, I'm assuming
"CURLAUTH_ANY" is not supported.

Also, I do not have access to a NTLM proxy, so I cannot test that
behaviour. Would someone be able to confirm or deny this bug?


Kind regards,
Steve

Re: http.c (curl_easy_setopt and CURLAUTH_ANY)

[Daniel Stenberg]

On Fri, 28 Aug 2015, Stephen Kazakoff wrote:

> From:
> curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
>
> To:
> curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_BASIC | CURLAUTH_NTLM);
>
> I did however find the CURL documentation 
> (https://secure.php.net/manual/en/function.curl-setopt.php) slightly 
> conflicting. On one hand, "CURLAUTH_ANY" is effectively the same as passing 
> "CURLAUTH_BASIC | CURLAUTH_NTLM". But the documentation for 
> "CURLOPT_PROXYAUTH" says that only "CURLAUTH_BASIC" and "CURLAUTH_NTLM" are 
> currently supported. By that, I'm assuming "CURLAUTH_ANY" is not supported.

That would rather indicate a problem somewhere else.

CURLAUTH_ANY is just a convenience define that sets a bunch of bits at once, 
and libcurl will discard bits you'd set for auth methods your libcurl hasn't 
been built to deal with anyway. Thus, the above two lines should result in 
(almost) exactly the same behavior from libcurl's point of view.

The fact that they actually make a difference is probably because ANY then 
enables a third authentication method that perhaps your server doesn't like? 
Or is it a libcurl bug?

Hard to tell without more info, including libcurl version. But no, the above 
suggested change doesn't really make much sense for the general population.

-- 

  / daniel.haxx.se

Re: http.c (curl_easy_setopt and CURLAUTH_ANY)

[Johannes Schindelin]

Hi Stephen,

On 2015-08-28 08:07, Stephen Kazakoff wrote:

> When I'm behind a proxy (with BASIC authentication), I'm unable to
> perform a git clone.
> 
> I managed to fix this by editing http.c and recompiling. The change
> I'd like to propose is to line 452.
> 
> 
> From:
> 
> curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
> 
> To:
> 
> curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_BASIC | CURLAUTH_NTLM);

But `CURLAUTH_ANY` should imply `_BASIC` and `_NTLM`. I remember that the `_ANY` was supposed to avoid hard-coding things.

According to

    https://github.com/bagder/curl/blob/ac7be02e695af95e93b3f5a40b80dcab782f5321/include/curl/curl.h#L651

it should actually imply even more. Maybe that is the problem? Could you debug further by setting the environment variable GIT_CURL_VERBOSE=1?

Ciao,
Johannes

Re: http.c (curl_easy_setopt and CURLAUTH_ANY)

[brian m. carlson]

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

On Fri, Aug 28, 2015 at 04:07:36PM +1000, Stephen Kazakoff wrote:
> Hi,
> 
> When I'm behind a proxy (with BASIC authentication), I'm unable to
> perform a git clone.
> 
> I managed to fix this by editing http.c and recompiling. The change
> I'd like to propose is to line 452.
> 
> 
> From:
> 
> curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
> 
> To:
> 
> curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_BASIC | CURLAUTH_NTLM);

Assuming it's supported upstream, I suspect this would break people who
are using GSSAPI (or Digest) authentication for their proxy.  This would
be a logical thing to do where Kerberos is used.

It might be worth checking exactly which bits cause problems for you;
perhaps your proxy might be misconfigured to suggest a type that it
doesn't support.

> I did however find the CURL documentation
> (https://secure.php.net/manual/en/function.curl-setopt.php) slightly
> conflicting. On one hand, "CURLAUTH_ANY" is effectively the same as
> passing "CURLAUTH_BASIC | CURLAUTH_NTLM". But the documentation for
> "CURLOPT_PROXYAUTH" says that only "CURLAUTH_BASIC" and
> "CURLAUTH_NTLM" are currently supported. By that, I'm assuming
> "CURLAUTH_ANY" is not supported.

This looks like the documentation for PHP.  The libcurl documentation[0]
doesn't mention a limitation.

[0] http://curl.haxx.se/libcurl/c/CURLOPT_PROXYAUTH.html
-- 
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: 835 bytes --]