[ curl-Bugs-1004841 ] --negotiate does not work without username/password

[brianjmurrell]

Just to breathe new life into a bug that was closed prematurely (IMHO) 12 years ago...

I did this

$ cat < ~/.curlrc
-H "Pragma:"
--proxy-negotiate
-x http://proxy:3128
EOF
$ curl -L -v -o /dev/null 'http://www.ibm.com/'

I expected the following

Fetch the URL, using my GSSAPI ticket

But this happened instead

curl failed to fetch because I also need to put -u : on the command line which sends a bogus Basic Auth credential as well

curl/libcurl version

$ curl --version
curl 7.51.0 (x86_64-redhat-linux-gnu) libcurl/7.51.0 NSS/3.27 zlib/1.2.8 libidn2/0.11 libpsl/0.14.0 (+libidn2/0.10) libssh2/1.8.0 nghttp2/1.13.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets Metalink PSL

operating system

CentOS 7.2

I really shouldn't have to configure a bogus username/password to use an auth method that doesn't require it. IMHO.

[bagder]

There's no need to file a known bug again. See https://curl.haxx.se/docs/knownbugs.html#Negotiate_and_Kerberos_V5_need_a

[Khalian]

I actually have a fix for this but it was never merged (as it was a credential acquisition via the MIT kerberos API). It also covers other ways of authentication. It was shot down quite a while ago.

https://github.com/Khalian/curl/blob/master/lib/curl_gssapi.c

For the full commit see : Khalian@552ee86

[brianjmurrell]

@bagder It doesn't make sense to have a ticket held open for a known bug? If it's left open, here, it's there for the next person who comes searching for it before they file a ticket, like I did. And it's there for people to up-vote. And it's also there for a person who comes along looking for something to work on.

I (now) realise that you have a separate system (https://curl.haxx.se/docs/knownbugs.html) but there is no reason I would have thought there was a separate system for listing known bugs when there is this perfectly good (and pretty standard way of working) ticket system here.

Perhaps at least, add a line to the top of your ticket template pointing to the known bugs list so that people know that it's there.

[brianjmurrell]

@Khalian That's a pretty big commit. Is there a PR for it? Perhaps it needs breaking down into smaller pieces addressing particular issues.

[bagder]

Perhaps at least, add a line to the top of your ticket template

Okay thanks, trying out something along those lines now...

[Khalian]

@brianjmurrell Yes it is. It's also awkward to reconcile this with the official branch of curl.

On one hand there is no way to acquire a gss cred without calling the lower layer (in my case MIT kerberos directly). On the other hand that locks the negotiate protocol to kerberos altogether. If @bagder thinks that pigeonholing MIT kerb into gssapi is a good idea, I can send out PRs chunking it into managable sizes. The last time I submitted patches of this sort it was shot down.

[bagder]

If @bagder thinks that pigeonholing MIT kerb into gssapi is a good idea

I can't really tell without seeing the exact patch as a general statement, but if you say we already "shot it down" in the past I'd say chances are that we (I?) still think the same if the patch is the same. I don't remember the patch and I couldn't really work out the change from the link to that github repo either - it seems to contain a lot of (for this case) irrelevant changes.

[brianjmurrell]

That's why I suggested he break it down into smaller pieces and submit it as a PR. That way it can be reviewed and an audit trail of the review will be there for now and for future archaeology.

[Khalian]

"I don't remember the patch and I couldn't really work out the change from the link to that github repo either - it seems to contain a lot of (for this case) irrelevant changes"

That particular commit was all my extensions to curl for MIT Kerberos (credential cache, keytab, username password etc). There were also other things (like memory leaks in the SPNEGO path).

[bagder]

If there were legitimate issues fixed in that patch, I would prefer to get them filed as separate patches/commits so that we can merge bug fixes independently from features/changes that are irrelevant to the bug fixes and those features/changes can be discussed separately on their own merits.

As described in the CONTRIBUTE document.