The {MD5,SHA1,SHA256}_Init functions from OpenSSL are called directly
without any wrappers and they return 1 for success, 0 otherwise.  Hence,
we have to use the same approach in all the wrapper functions that are
used for the other crypto libraries.

This commit fixes a regression introduced in commit dca8ae5f.

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

When using only 1 second precision, curl doesn't create new cnonce
values quickly enough for all uses.

For example, issuing the following command multiple times to a recent
Tomcat causes authentication failures:

curl --digest -utest:test http://tomcat.test.com:8080/manager/list

This is because curl uses the same cnonce for several seconds, but
doesn't increment the nonce counter.  Tomcat correctly interprets
this as a replay attack and rejects the request.

When microsecond-precision is available, this commit causes curl to
change cnonce values much more frequently.

With microsecond resolution, increasing the nounce length used in the
headers to 32 was made to further reduce the risk of duplication.

Instead of relying on the generic CURLE error for SCP or SFTP send
failures, try passing back a more suitable error if possible.

Fixes bug #3578163:
http://sourceforge.net/tracker/?func=detail&atid=100976&aid=3578163&group_id=976

... to release resources allocated at global scope

and make local function static

axTLS:

This will make the axTLS backend perform the RFC2818 checks, honoring
the VERIFYHOST setting similar to the OpenSSL backend.

Generic for OpenSSL and axTLS:

Move the hostcheck and cert_hostcheck functions from the lib/ssluse.c
files to make them genericly available for both the OpenSSL, axTLS and
other SSL backends. They are now in the new lib/hostcheck.c file.

CyaSSL:

CyaSSL now also has the RFC2818 checks enabled by default. There is a
limitation that the verifyhost can not be enabled exclusively on the
Subject CN field comparison. This SSL backend will thus behave like the
NSS and the GnuTLS (meaning: RFC2818 ok, or bust). In other words:
setting verifyhost to 0 or 1 will disable the Subject Alt Names checks
too.

Schannel:

Updated the schannel information messages: Split the IP address usage
message from the verifyhost setting and changed the message about
disabling SNI (Server Name Indication, used in HTTP virtual hosting)
into a message stating that the Subject Alternative Names checks are
being disabled when verifyhost is set to 0 or 1. As a side effect of
switching off the RFC2818 related servername checks with
SCH_CRED_NO_SERVERNAME_CHECK
(http://msdn.microsoft.com/en-us/library/aa923430.aspx) the SNI feature
is being disabled. This effect is not documented in MSDN, but Wireshark
output clearly shows the effect (details on the libcurl maillist).

PolarSSL:

Fix the prototype change in PolarSSL of ssl_set_session() and the move
of the peer_cert from the ssl_context to the ssl_session. Found this
change in the PolarSSL SVN between r1316 and r1317 where the
POLARSSL_VERSION_NUMBER was at 0x01010100. But to accommodate the Ubuntu
PolarSSL version 1.1.4 the check is to discriminate between lower then
PolarSSL version 1.2.0 and 1.2.0 and higher. Note: The PolarSSL SVN
trunk jumped from version 1.1.1 to 1.2.0.

Generic:

All the SSL backends are fixed and checked to work with the
ssl.verifyhost as a boolean, which is an internal API change.

Since we added the curl_multi_wait function, the VERSIONINFO needed
updating.

Reported by: Patrick Monnerat

Requested by Johnny Luong on the libcurl list.

The text "additional stuff not fine" text was added for debug purposes a
while ago, but it isn't really helping anyone and for some reason some
Linux distributions provide their libcurls built with debug info still
present and thus (far too many) users get to read this info.

6 new bugfixes and 3 more contributors...

The logic previously checked for a started NTLM negotiation only for
host and not also with proxy, leading to problems doing POSTs over a
proxy NTLM that are larger than 2000 bytes. Now it includes proxy in the
check.

Bug: http://curl.haxx.se/bug/view.cgi?id=3582321
Reported by: John Suprock

The bug report claimed it didn't work. This problem was probably fixed
in 473003fb.

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

The existing logic only cut off the fragment from the separate 'path'
buffer which is used when sending HTTP to hosts. The buffer that held
the full URL used for proxies were not dealt with. It is now.

Test case 5 was updated to use a fragment on a URL over a proxy.

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

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

With the reversion of ce8311c7 and the new clear logic, this flaw
is present and we allow it.

As a handle can be re-used after having done HTTP auth in a previous
request, it must make sure to clear out the HTTP types that aren't
wanted in this new request.

This test case verifies that bug 3582718 is fixed.

Bug: http://curl.haxx.se/bug/view.cgi?id=3582718
Reported by: Nick Zitzmann (originally)

This reverts commit ce8311c7.

The commit made test 2024 work but caused a regression with repeated
Digest authentication. We need to fix this differently.

After a research team wrote a document[1] that found several live source
codes out there in the wild that misused the CURLOPT_SSL_VERIFYHOST
option thinking it was a boolean, this change now bans 1 as a value and
will make libcurl return error for it.

1 was never a sensible value to use in production but was introduced
back in the days to help debugging. It was always documented clearly
this way.

1 was never supported by all SSL backends in libcurl, so this cleanup
makes the treatment of it unified.

The report's list of mistakes for this option were all PHP code and
while there's a binding layer between libcurl and PHP, the PHP team has
decided that they have an as thin layer as possible on top of libcurl so
they will not alter or specifically filter a 'TRUE' value for this
particular option. I sympathize with that position.

[1] = http://daniel.haxx.se/blog/2012/10/25/libcurl-claimed-to-be-dangerous/

Since automake 1.12.4, the warnings are issued on running automake:

  warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')

Avoid INCLUDES and roll these flags into AM_CPPFLAGS.

Compile tested on:
  Ubuntu 10.04 (automake 1:1.11.1-1)
  Ubuntu 12.04 (automake 1:1.11.3-1ubuntu2)
  Arch Linux (automake 1.12.4)

Oops, my previous commit broke builds with krb support.