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 bail out if the
server actually said anything *back* to us in the negotiation. We assume
that we send a single token to the server, and it accepts it. If the server
wants to continue the exchange (as is required for NTLM and for SPNEGO
to do anything useful), then curl was broken anyway.

So the only bit which actually did anything was the bit in
Curl_output_negotiate(), which always generates an *initial* SPNEGO
token saying "Hey, I support only the Kerberos mechanism and this is its
token".

You could have done that by manually just prefixing the Kerberos token
with the appropriate bytes, if you weren't going to do any proper SPNEGO
handling. There's no need for the FBOpenSSL library at all.

The sane way to do SPNEGO is just to *ask* the GSSAPI library to do
SPNEGO. That's what the 'mech_type' argument to gss_init_sec_context()
is for. And then it should all Just Work™.

That 'sane way' will be added in a subsequent patch, as will bug fixes
for our failure to handle any exchange other than a single outbound
token to the server which results in immediate success.

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.

... 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

Reported-by: David Woodhouse

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 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.

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

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.

... and spell it as crl_der instead of crlDER

When an error has been detected, skip the final forced call to the
progress callback by making sure to pass the current return code
variable in the Curl_done() call in the CURLM_STATE_DONE state.

This avoids the "extra" callback that could occur even if you returned
error from the progress callback.

Bug: http://curl.haxx.se/mail/lib-2014-06/0062.html
Reported by: Jonathan Cardoso Machado

This feature was unintentionally disabled by commit ff92fcfb.

... due to calling SSL_VersionRangeGet() with NULL file descriptor

reported-by: upstream tests 305 and 404

c-ares now does support IPv6;
avoid implying threaded resolver is Windows-only;
two referenced source files were renamed in 7de2f927

This caused segfaults on tests 823 869 907.

The static connection counter caused a race condition. Moving the
connection id counter into conncache solves it, as well as simplifying
the related logic.

This regression was introduced when *init was split into *init and
*setup...

They were added because of an older code path that used allocations and
should not have been left in the code. With this change the logic goes
back to how it was.

Curl_rand() will return a dummy and repatable random value for this
case. Makes it possible to write test cases that verify output.

Also, fake timestamp with CURL_FORCETIME set.

Only when built debug enabled of course.

Curl_ssl_random() was not used anymore so it has been
removed. Curl_rand() is enough.

create_digest_md5_message: generate base64 instead of hex string

curl_sasl: also fix memory leaks in some OOM situations

httpproxycode is not reset in Curl_initinfo, so a 407 is not reset even
if curl_easy_reset is called between transfers.

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

The method change is forbidden by the obsolete RFC2616, but libcurl did
it anyway for compatibility reasons. The new RFC7231 allows this
behaviour so there's no need for the scary "Violate RFC 2616/10.3.x"
notice. Also update the comments accordingly.

Bug: http://curl.haxx.se/bug/view.cgi?id=1378
Reported and Patched-by: Marcel Raad

Bug: http://curl.haxx.se/mail/lib-2014-06/0003.html
Reported-by: Дмитрий Фалько