Coverity CID 1215284. The server name is extracted with
Curl_copy_header_value() and passed in to this function, and
copy_header_value can actually can fail and return NULL.

For private keys, use the first match from: user-specified key file
(if provided), ~/.ssh/id_rsa, ~/.ssh/id_dsa, ./id_rsa, ./id_dsa

Note that the previous code only looked for id_dsa files. id_rsa is
now generally preferred, as it supports larger key sizes.

For public keys, use the user-specified key file, if provided.
Otherwise, try to extract the public key from the private key file.
This means that passing --pubkey is typically no longer required,
and makes the key-handling behavior more like OpenSSH.

Coverity CID 1202836. If the proxy environment variable returned an empty
string, it would be leaked. While an empty string is not really a proxy, other
logic in this function already allows a blank string to be returned so allow
that here to avoid the leak.

Coverity CID 1202837. There's a potential risk that 'newurl' gets
overwritten when it was already pointing to allocated memory.

Coverity CID 1215287. There's a potential risk for a memory leak in
here, and moving the free call to be unconditional seems like a cheap
price to remove the risk.

Coverity CID 1215296. There's a potential risk for a memory leak in
here, and moving the free call to be unconditional seems like a cheap
price to remove the risk.

Coverity detected this. CID 1241954. When Curl_poll() returns a negative value
'mcode' was uninitialized. Pretty harmless since this is debug code only and
would at worst cause an error to _not_ be returned...

and separate the example URLs with newlines

This patch fixes the "SSL3_WRITE_PENDING: bad write retry" error that
sometimes occurs when sending an email over SMTPS with OpenSSL. OpenSSL
appears to require the same pointer on a write that follows a retry
(CURLE_AGAIN) as discussed here:

http://stackoverflow.com/questions/2997218/why-am-i-getting-error1409f07fssl-routinesssl3-write-pending-bad-write-retr

Mostly because we use C strings and they end at a binary zero so we know
we can't open a file name using an embedded binary zero.

Reported-by:  <research@g0blin.co.uk>

The switch to using Curl_expire_latest() in commit cacdc27f was a
mistake and was against the advice even mentioned in that commit. The
comparison in asyn-thread.c:Curl_resolver_is_resolved() makes
Curl_expire() the suitable function to use.

Bug: http://curl.haxx.se/bug/view.cgi?id=1426
Reported-By: graysky

Added initial support for WinIDN build configurations to the VC10+
project files.

As we weren't using the correct phonetic description and doing it correctly
involves funny letters that I'm sure will cause problems for people in a text
document so I instead rephrased it and link to a WAV file with a person
actually saying 'curl'.

Reported-By: Dimitar Boevski

Reported-By: Jonathan Cardoso Machado
URL: http://curl.haxx.se/mail/lib-2014-09/0102.html

... to further remove specific TLS backend knowledge from url.c

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.