The internal libcurl function called sanitize_cookie_path() that cleans
up the path element as given to it from a remote site or when read from
a file, did not properly validate the input. If given a path that
consisted of a single double-quote, libcurl would index a newly
allocated memory area with index -1 and assign a zero to it, thus
destroying heap memory it wasn't supposed to.

CVE-2015-3145

Bug: http://curl.haxx.se/docs/adv_20150422C.html
Reported-by: Hanno Böck

CVE-2015-3143

Bug: http://curl.haxx.se/docs/adv_20150422A.html
Reported-by: Paras Sethia

Bug: https://github.com/bagder/curl/issues/229
Reported-by: bsammon

Reported-by: John Marshall
Bug: https://github.com/bagder/curl/issues/225

... and some minor edits

This reverts commit 5dc68dd6.

Bug: https://github.com/bagder/curl/issues/223
Reported-by: Michael Osipov

Prior to this change CyaSSL's build options could redefine some generic
build symbols.

http://curl.haxx.se/mail/lib-2015-04/0069.html

Bug: https://github.com/bagder/curl/pull/171

When a config file line ends without newline, the parsing function could
continue reading beyond that point in memory.

Reported-by: Hanno Böck

At some point, Firefox has changed and generates different directory
names for the default profile that made this script fail to find them.

Bug: https://github.com/bagder/curl/issues/207
Reported-by: sneakyimp

CyaSSL >= 2.6.0 may have an options.h that was generated during
its build by configure.

Prior to this change Visual Studio builds could fail due to missing
prerequisites src/tool_hugehelp.c and include/curl/curlbuild.h.

http://curl.haxx.se/mail/lib-2015-04/0034.html

Add 'gdi32' and 'crypt32' Windows implibs to avoid failure
while building libcurl.dll using the mingw compiler.
The same logic is used in 'src/makefile.m32' when
building curl.exe.

... of an empty file

Bug: https://github.com/bagder/curl/issues/183

The factor of 8 is a bytes-to-bits conversion factor, but pkt_size and
rate_bps are both in bytes. When using the rate limiting option, curl
waits 8 times too long, and then transfers very quickly until the
average rate reaches the limit. The average rate follows the limit over
time, but the actual traffic is bursty.

Thanks-to: Benjamin Gilbert

The key length in bits will always fit in an unsigned long so the
loss-of-data warning assigning the result of x64 pointer arithmetic to
an unsigned long is unnecessary.