Negotiate ignored with --anyauth

[dfandrich]

I did this

The current curl 8.21.0-DEV (commit 81cdf4d) ignores a WWW-Authenticate: Negotiate header when run with --anyauth without -u and does not attempt to negotiate Kerberos authentication. If run with --negotiate instead of --anyauth, it negotiates fine and succeeds. This used to work, e.g. in 8.20.0, 8.11.1 (and many others). The command-lines used are like curl -v --anyauth -k -u : https://example.com/protected. I believe some curl versions will work as well dropping the -u :.

As a workaround, adding a dummy, non-blank username (and optionally password) instead of : (e.g. -u literally:anything) in the command-line above causes negotiation to be performed again (and succeed) on master. Some historical curl versions work with Negotiate given -u : and others (IIRC) with no -u option at all, but as of this bug, a third way of making it work (dummy, non-blank data) seems to have been created.

The documentation for -u does mention including a Windows domain name for Kerberos on Windows (which is not relevant to my system), and it also says to use -u : to obtain the username automatically (but it also says this only on Windows). So, I don't think this change is desired, especially since the actual contents of the given username seems to be thrown out.

I didn't see any test cases for this, i.e. a server with Negotiate only and -u :.

I was able to bisect the issue to commit 8f71d0f "creds: hold credentials" (May 11, 2026).

I expected the following

-u : should be enough for --anyauth to work for Negotiate.

curl/libcurl version

8.21.0-DEV

operating system

Linux x86_64

[bagder]

Negotiate is a crazy auth, which makes it hard to test which makes regressions happen easily. ☹️

[mjcheetham]

Confirming the same regression from a different consumer and a different platform.

I hit it via Git's t5563-simple-http-auth.sh test 18 on Git 2.55.0-rc0, originally reported on the git mailing list at https://lore.kernel.org/git/20260611210456.XYfhytSL@teonanacatl.net/.

I bisected libcurl independently and landed on the same commit.

Git has used CURLOPT_USERPWD = ":" since 121061f67f (Feb 2016) as the way to ask libcurl to attempt Negotiate from the caller's ambient Kerberos ticket cache without supplying a username/password. The original commit message named the libcurl constraint it was working around:

libcurl refuses to perform authentication if it has not been provided with a username and password. Add an option, http.emptyAuth, that provides libcurl with an empty username and password to make it attempt authentication anyway.

Mechanically, what Git does to drive SPNEGO via libcurl is:

1. Set CURLOPT_HTTPAUTH = CURLAUTH_ANY on every HTTP request so the CURLAUTH_GSSNEGOTIATE bit is always in the requested-auth bitmask.

2. When http.emptyAuth=auto decides Negotiate is worth a try (the server advertised it on a previous 401), set CURLOPT_USERPWD = ":" and re-issue the request.

3. Let libcurl observe the empty userpwd, route through the Negotiate auth scheme, call into GSS-API, and pick up whatever the caller's ambient ticket cache holds.

[icing]

A shot in the dark, but can you guys give #22044 a try? I lack the test env for this.

[vszakats]

This report posted to curl-library may also be related:
https://curl.se/mail/lib-2026-05/0012.html

[charles2910]

We got a report in debian too [1] for 8.21.0-rc2. I've pointed the reporter to Stefan's MR and asked if they can test.

[1] https://bugs.debian.org/1140043

[Vladimir-csp]

I can confirm, #22044 fixes Negotiate/GSS/Kerberos in Git

[mjcheetham]

I realise the behaviour of Negotiate/Kerberos when -u : (CURLOPT_USERPWD = ":") is not currently explicitly documented either in CURLOPT_USERPWD or CURLOPT_HTTPAUTH

Would explicit documentation be considered or welcome?

[bagder]

Would explicit documentation be considered or welcome?

it would be much welcomed!

[yoneyajp]

-u : worked for ldap scheme prior 8.20.0, but it doesn't work since 8.21.0. Probably related this issue.

$ curl -u : LDAP_URI
...
curl: (38) LDAP local: bind via ldap_win_bind 資格情報が無効です <-- Invalid credentials