It's wrong to assume that we can send a single SPNEGO packet which will
complete the authentication. It's a *negotiation* — the clue is in the
name. So make sure we handle responses from the server.

Curl_input_negotiate() will already handle bailing out if it thinks the
state is GSS_S_COMPLETE (or SEC_E_OK on Windows) and the server keeps
talking to us, so we should avoid endless loops that way.

GSSAPI doesn't work very well if we forget everything ever time.

XX: Is Curl_http_done() the right place to do the final cleanup?

This is the correct way to do SPNEGO. Just ask for it

Now I correctly see it trying NTLMSSP authentication when a Kerberos ticket
isn't available. Of course, we bail out when the server responds with the
challenge packet, since we don't expect that. But I'll fix that bug next...

This is just fundamentally broken. SPNEGO (RFC4178) is a protocol which
allows client and server to negotiate the underlying mechanism which will
actually be used to authenticate. This is *often* Kerberos, and can also
be NTLM and other things. And to complicate matters, there are various
different OIDs which can be used to specify the Kerberos mechanism too.

A SPNEGO exchange will identify *which* GSSAPI mechanism is being used,
and will exchange GSSAPI tokens which are appropriate for that mechanism.

But this SPNEGO implementation just strips the incoming SPNEGO packet
and extracts the token, if any. And completely discards the information
about *which* mechanism is being used. Then we *assume* it was Kerberos,
and feed the token into gss_init_sec_context() with the default
mechanism (GSS_S_NO_OID for the mech_type argument).

Furthermore... broken as this code is, it was never even *used* for input
tokens anyway, because higher layers of curl would just b...

Bumping it to 1KiB in commit aaaf9e50 is all very well, but having hit
a hard limit once let's just make it cope by reallocating as necessary.

After the fixed cookie lock deadlock, this test now passes and it
detects double-locking and double-unlocking of mutexes.

... by removing the extra mutex locks around th call to
Curl_flush_cookies() which takes care of the locking itself already.

Bug: http://curl.haxx.se/mail/lib-2014-02/0184.html

conversion to 'int' from 'long int' may alter its value

It's irrelevant to the test, and will change depending on which SSL
library is being used by libcurl.

Reported-by: David Woodhouse

Use ${host_alias}-krb5-config if available. This improves cross-
compilation support and fixes multilib on Gentoo (at least).

Before GnuTLS 3.3.6, the gnutls_x509_crt_check_hostname() function
didn't actually check IP addresses in SubjectAltName, even though it was
explicitly documented as doing so. So do it ourselves...

Reported-by: David Woodhouse

The old way using getpwuid could cause problems in programs that enable
reading from netrc files simultaneously in multiple threads.

Reported-by: David Woodhouse

This previously caused a fatal error (with a confusing error code, at
that).

Reported by: Glen A Johnson Jr.

Bug: http://curl.haxx.se/mail/lib-2014-07/0103.html
Reported-by: David Woodhouse

The curl tool project files for VC7 to VC12 would override the default
setting with the output filename being the same as the linker PDB file.
As such the compiler file would be overwritten with the linker file
for all debug builds.

To avoid this overwrite and for consistency with the libcurl project
files, removed the setting to force the default filename to be used.

The AES-GCM ciphers were added to GnuTLS as late as ver. 3.0.1 but
the code path in which they're referenced here is only ever used for
somewhat older GnuTLS versions. This caused undeclared identifier errors
when compiling against those.

This seems to have become necessary for SRP support to work starting
with GnuTLS ver. 2.99.0. Since support for SRP was added to GnuTLS
before the function that takes this priority string, there should be no
issue with backward compatibility.

These tests have been broken since commit 1958fe57 in Oct. 2011

This makes the behaviour consistent with what happens if a date can
be extracted from the certificate but is expired.

... with a mention of *NOSIGNAL, based on talk in bug #1386

This showed itself on some systems with torture failures
in tests 1060 and 1061

... pointed out by MSVC2013

Bug: http://curl.haxx.se/bug/view.cgi?id=1391

Otherwise NSS could use an already freed item for another connection.