Missed this in af45542c

.

Signed-off-by: Catalin Patulea <cat@vv.carleton.ca>

Previously we did not handle EOF from underlying transport socket and
wrongly just returned error code CURL_AGAIN from http2_recv, which
caused busy loop since socket has been closed.  This patch adds the
code to handle EOF situation and tells the upper layer that we got
EOF.

Bug: http://curl.haxx.se/bug/view.cgi?id=1422
Verified-by: Steve Holme

The former link was turned into a 404 at some point.

Reported-By: Askar Safin

... to support a list of names provided in a commit message.

Removed ISC_REQ_* flags from calls to InitializeSecurityContext to fix
bug in NTLM handshake for HTTP proxy authentication.

NTLM handshake for HTTP proxy authentication failed with error
SEC_E_INVALID_TOKEN from InitializeSecurityContext for certain proxy
servers on generating the NTLM Type-3 message.

The flag ISC_REQ_CONFIDENTIALITY seems to cause the problem according
to the observations and suggestions made in a bug report for the
QT project (https://bugreports.qt-project.org/browse/QTBUG-17322).

Removing all the flags solved the problem.

Bug: http://curl.haxx.se/mail/lib-2014-08/0273.html
Reported-by: Ulrich Telle
Assisted-by: Steve Holme, Daniel Stenberg

I use the curl repo mainly on Windows with the typical Windows git
checkout which converts the LF line endings in the curl repo to CRLF
automatically on checkout. The automatic conversion is not done on files
in the repo with mixed line endings. I recently noticed some weird
output with projects/build-openssl.bat that I traced back to mixed line
endings, so I scanned the repo and there are files (excluding the
test data) that have mixed line endings.

I used this command below to do the scan. Unfortunately it's not as easy
as git grep, at least not on Windows. This gets the names of all the
files in the repo's HEAD, gets each of those files raw from HEAD, checks
for mixed line endings of both LF and CRLF, and prints the name if
mixed. I excluded path tests/data/test* because those can have mixed
line endings if I understand correctly.

for f in `git ls-tree --name-only --full-tree -r HEAD`;
do if [ -n "${f##tests/data/test*}" ];
    then git show "HEAD:$f" | \
        perl -0777 -ne 'exit 1 if /([^\r]\n.*\r\n)|(\r\n.*[^\r]\n)/';
    if [ $? -ne 0 ];
        then echo "$f";
    fi;
fi;
done

It interprets them as italic indictors unless we backtick the word.

Added support for Kerberos 5 to the email protocols following the recent
additions in 7.38.0.

Removed Kerberos 4 as this has been gone for a while now.

Bug: http://curl.haxx.se/mail/lib-2014-09/0064.html

As a sort of step forward, this script will now first try to get the
data from the HTTPS URL using curl, and only if that fails it will
switch back to the HTTP transfer using perl's native LWP functionality.
To reduce the risk of this script being tricked.

Using HTTPS to get a cert bundle introduces a chicken-and-egg problem so
we can't really ever completely disable HTTP, but chances are that most
users already have a ca cert bundle that trusts the mozilla.org site
that this script downloads from.

A future version of this script will probably switch to require a
dedicated "insecure" command line option to allow downloading over HTTP
(or unverified HTTPS).

krb4 has been dropped since a while now

Edited format to look better on the web, added a "it is about trust"
section.

CMake/FindOpenSSL.cmake and FindZLIB.cmake are gone since 14aa8f0c

Test 61 was modified to verify this.

CVE-2014-3620

Reported-by: Tim Ruehsen
URL: http://curl.haxx.se/docs/adv_20140910B.html

By not detecting and rejecting domain names for partial literal IP
addresses properly when parsing received HTTP cookies, libcurl can be
fooled to both send cookies to wrong sites and to allow arbitrary sites
to set cookies for others.

CVE-2014-3613

Bug: http://curl.haxx.se/docs/adv_20140910A.html

Only minor edits to make it generate nice HTML output using markdown, as
this document serves both in source release tarballs as on the web site.

URL: http://curl.haxx.se/docs/sslcerts.html

Reported-By: Frank Gevaerts

Signed-off-by: Catalin Patulea <cat@vv.carleton.ca>

Historically the default "unknown" value for progress.size_dl and
progress.size_ul has been zero, since these values are initialized
implicitly by the calloc that allocates the curl handle that these
variables are a part of.  Users of curl that install progress
callbacks may expect these values to always be >= 0.

Currently it is possible for progress.size_dl and progress.size_ul
to by set to a value of -1, if Curl_pgrsSetDownloadSize() or
Curl_pgrsSetUploadSize() are passed a "size" of -1 (which a few
places currently do, and a following patch will add more).  So
lets update Curl_pgrsSetDownloadSize() and Curl_pgrsSetUploadSize()
so they make sure that these variables always contain a value that
is >= 0.

Updates test579 and test599.

Signed-off-by: Brandon Casey <drafnel@gmail.com>