... instead of truncating them.
There's no fixed limit for acceptable cookie names in RFC 6265, but the
entire cookie is said to be less than 4096 bytes (section 6.1). This is
also what browsers seem to implement.
We now allow max 5000 bytes cookie header. Max 4095 bytes length per
cookie name and value. Name + value together may not exceed 4096 bytes.
Added test 1151 to verify
Bug: https://curl.haxx.se/mail/lib-2017-09/0062.html
Reported-by: Kevin Smith
Closes#1894
lib/vtls/openssl.c uses OpenSSL APIs from BUF_MEM and BIO APIs. Include
their headers directly rather than relying on other OpenSSL headers
including things.
Closes https://github.com/curl/curl/pull/1891
If the INTERLEAVEFUNCTION is defined, then use that plus the
INTERLEAVEDATA information when writing RTP. Otherwise, use
WRITEFUNCTION and WRITEDATA.
Fixes#1880Closes#1884
If the default write callback is used and no destination has been set, a
NULL pointer would be passed to fwrite()'s 4th argument.
OSS-fuzz bug https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3327
(not publicly open yet)
Detected by OSS-fuzz
Closes#1874
`conn->connect_state` is NULL when doing a regular non-CONNECT request
over the proxy and should therefor be considered complete at once.
Fixes#1853Closes#1862
Reported-by: Lawrence Wagerfield
Another mistake in my manual fixups of the largely mechanical
search-and-replace ("connssl->" -> "BACKEND->"), just like the previous
commit concerning HTTPS proxies (and hence not caught during my
earlier testing).
Fixes#1855Closes#1871
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In d65e6cc4f (vtls: prepare the SSL backends for encapsulated private
data, 2017-06-21), this developer prepared for a separation of the
private data of the SSL backends from the general connection data.
This conversion was partially automated (search-and-replace) and
partially manual (e.g. proxy_ssl's backend data).
Sadly, there was a crucial error in the manual part, where the wrong
handle was used: rather than connecting ssl[sockindex]' BIO to the
proxy_ssl[sockindex]', we reconnected proxy_ssl[sockindex]. The reason
was an incorrect location to paste "BACKEND->"... d'oh.
Reported by Jay Satiro in https://github.com/curl/curl/issues/1855.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Ever since 70f1db321 (vtls: encapsulate SSL backend-specific data,
2017-07-28), the code handling HTTPS proxies was broken because the
pointer to the SSL backend data was not swapped between
conn->ssl[sockindex] and conn->proxy_ssl[sockindex] as intended, but
instead set to NULL (causing segmentation faults).
[jes: provided the commit message, tested and verified the patch]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
... instead of the prefix-less version since WolfSSL 3.12 now uses an
enum with that name that causes build failures for us.
Fixes#1865Closes#1867
Reported-by: Gisle Vanem
- The part kind MIMEKIND_FILE and associated code are suppressed.
- Seek data origin offset not used anymore: suppressed.
- MIMEKIND_NAMEDFILE renamed MIMEKIND_FILE; associated fields/functions
renamed accordingly.
- Curl_getformdata() processes stdin via a callback.
Back in 2008, (and commit 3f3d6ebe66) we changed the logic in how we
determine the native type for `curl_off_t`. To really make sure we
didn't break ABI without bumping SONAME, we introduced logic that
attempted to detect that it would use a different size and thus not be
compatible. We also provided a manual switch that allowed users to tell
configure to bump SONAME by force.
Today, we know of no one who ever got a SONAME bump auto-detected and we
don't know of anyone who's using the manual bump feature. The auto-
detection is also no longer working since we introduced defining
curl_off_t in system.h (7.55.0).
Finally, this bumping logic is not present in the cmake build.
Closes#1861
This is an adaptation of 2 of Peter Wu's SSLKEYLOGFILE implementations.
The first one, written for old OpenSSL versions:
https://git.lekensteyn.nl/peter/wireshark-notes/tree/src/sslkeylog.c
The second one, written for BoringSSL and new OpenSSL versions:
https://github.com/curl/curl/pull/1346
Note the first one is GPL licensed but the author gave permission to
waive that license for libcurl.
As of right now this feature is disabled by default, and does not have
a configure option to enable it. To enable this feature define
ENABLE_SSLKEYLOGFILE when building libcurl and set environment
variable SSLKEYLOGFILE to a pathname that will receive the keys.
And in Wireshark change your preferences to point to that key file:
Edit > Preferences > Protocols > SSL > Master-Secret
Co-authored-by: Peter Wu
Ref: https://github.com/curl/curl/pull/1030
Ref: https://github.com/curl/curl/pull/1346
Closes https://github.com/curl/curl/pull/1866
curl_mime_encoder() is operational and documented.
curl tool -F option is extended with ";encoder=".
curl tool --libcurl option generates calls to curl_mime_encoder().
New encoder tests 648 & 649.
Test 1404 extended with an encoder specification.
Up2date versions of OpenSSL maintain the default reasonably secure
without breaking compatibility, so it is better not to override the
default by curl. Suggested at https://bugzilla.redhat.com/1483972Closes#1846
To support telling a string is nul-terminated, symbol CURL_ZERO_TERMINATED
has been introduced.
Documentation updated accordingly.
symbols in versions updated. Added form API symbols deprecation info.
This feature is badly supported in Windows: as a replacement, a caller has
to use curl_mime_data_cb() with fread, fseek and possibly fclose
callbacks to process opened files.
The cli tool and documentation are updated accordingly.
The feature is however kept internally for form API compatibility, with
the known caveats it always had.
As a side effect, stdin size is not determined by the cli tool even if
possible and this results in a chunked transfer encoding. Test 173 is
updated accordingly.
Some calls in different modules were setting the data handle to NULL, causing
segmentation faults when using builds that enable character code conversions.
destroy_async_data() assumes that if the flag "done" is not set yet, the
thread itself will clean up once the request is complete. But if an
error (generally OOM) occurs before the thread even has a chance to
start, it will never get a chance to clean up and memory will be leaked.
By clearing "done" only just before starting the thread, the correct
cleanup sequence will happen in all cases.
Previously, we used as default SSL backend whatever was first in the
`available_backends` array.
However, some users may want to override that default without patching
the source code.
Now they can: with the --with-default-ssl-backend=<backend> option of
the ./configure script.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When only one SSL backend is configured, it is totally unnecessary to
let multissl_init() configure the backend at runtime, we can select the
correct backend at build time already.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Let's add a compile time safe API to select an SSL backend. This
function needs to be called *before* curl_global_init(), and can be
called only once.
Side note: we do not explicitly test that it is called before
curl_global_init(), but we do verify that it is not called multiple times
(even implicitly).
If SSL is used before the function was called, it will use whatever the
CURL_SSL_BACKEND environment variable says (or default to the first
available SSL backend), and if a subsequent call to
curl_global_sslset() disagrees with the previous choice, it will fail
with CURLSSLSET_TOO_LATE.
The function also accepts an "avail" parameter to point to a (read-only)
NULL-terminated list of available backends. This comes in real handy if
an application wants to let the user choose between whatever SSL backends
the currently available libcurl has to offer: simply call
curl_global_sslset(-1, NULL, &avail);
which will return CURLSSLSET_UNKNOWN_BACKEND and populate the avail
variable to point to the relevant information to present to the user.
Just like with the HTTP/2 push functions, we have to add the function
declaration of curl_global_sslset() function to the header file
*multi.h* because VMS and OS/400 require a stable order of functions
declared in include/curl/*.h (where the header files are sorted
alphabetically). This looks a bit funny, but it cannot be helped.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There is information about the compiled-in SSL backends that is really
no concern of any code other than the SSL backend itself, such as which
function (if any) implements SHA-256 summing.
And there is information that is really interesting to the user, such as
the name, or the curl_sslbackend value.
Let's factor out the latter into a publicly visible struct. This
information will be used in the upcoming API to set the SSL backend
globally.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When building software for the masses, it is sometimes not possible to
decide for all users which SSL backend is appropriate.
Git for Windows, for example, uses cURL to perform clones, fetches and
pushes via HTTPS, and some users strongly prefer OpenSSL, while other
users really need to use Secure Channel because it offers
enterprise-ready tools to manage credentials via Windows' Credential
Store.
The current Git for Windows versions use the ugly work-around of
building libcurl once with OpenSSL support and once with Secure Channel
support, and switching out the binaries in the installer depending on
the user's choice.
Needless to say, this is a super ugly workaround that actually only
works in some cases: Git for Windows also comes in a portable form, and
in a form intended for third-party applications requiring Git
functionality, in which cases this "swap out libcurl-4.dll" simply is
not an option.
Therefore, the Git for Windows project has a vested interest in teaching
cURL to make the SSL backend a *runtime* option.
This patch makes that possible.
By running ./configure with multiple --with-<backend> options, cURL will
be built with multiple backends.
For the moment, the backend can be configured using the environment
variable CURL_SSL_BACKEND (valid values are e.g. "openssl" and
"schannel").
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
So far, all of the SSL backends' private data has been declared as
part of the ssl_connect_data struct, in one big #if .. #elif .. #endif
block.
This can only work as long as the SSL backend is a compile-time option,
something we want to change in the next commits.
Therefore, let's encapsulate the exact data needed by each SSL backend
into a private struct, and let's avoid bleeding any SSL backend-specific
information into urldata.h. This is also necessary to allow multiple SSL
backends to be compiled in at the same time, as e.g. OpenSSL's and
CyaSSL's headers cannot be included in the same .c file.
To avoid too many malloc() calls, we simply append the private structs
to the connectdata struct in allocate_conn().
This requires us to take extra care of alignment issues: struct fields
often need to be aligned on certain boundaries e.g. 32-bit values need to
be stored at addresses that divide evenly by 4 (= 32 bit / 8
bit-per-byte).
We do that by assuming that no SSL backend's private data contains any
fields that need to be aligned on boundaries larger than `long long`
(typically 64-bit) would need. Under this assumption, we simply add a
dummy field of type `long long` to the `struct connectdata` struct. This
field will never be accessed but acts as a placeholder for the four
instances of ssl_backend_data instead. the size of each ssl_backend_data
struct is stored in the SSL backend-specific metadata, to allow
allocate_conn() to know how much extra space to allocate, and how to
initialize the ssl[sockindex]->backend and proxy_ssl[sockindex]->backend
pointers.
This would appear to be a little complicated at first, but is really
necessary to encapsulate the private data of each SSL backend correctly.
And we need to encapsulate thusly if we ever want to allow selecting
CyaSSL and OpenSSL at runtime, as their headers cannot be included within
the same .c file (there are just too many conflicting definitions and
declarations for that).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
At the moment, cURL's SSL backend needs to be configured at build time.
As such, it is totally okay for them to hard-code their backend-specific
data in the ssl_connect_data struct.
In preparation for making the SSL backend a runtime option, let's make
the access of said private data a bit more abstract so that it can be
adjusted later in an easy manner.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In 86b889485 (sasl_gssapi: Added GSS-API based Kerberos V5 variables,
2014-12-03), an SSPI-specific field was added to the kerberos5data
struct without moving the #include "curl_sspi.h" later in the same file.
This broke the build when SSPI was enabled, unless Secure Channel was
used as SSL backend, because it just so happens that Secure Channel also
requires "curl_sspi.h" to be #included.
In f4739f639 (urldata: include curl_sspi.h when Windows SSPI is enabled,
2017-02-21), this bug was fixed incorrectly: Instead of moving the
appropriate conditional #include, the Secure Channel-conditional part
was now also SSPI-conditional.
Fix this problem by moving the correct #include instead.
This is also required for an upcoming patch that moves all the Secure
Channel-specific stuff out of urldata.h and encapsulates it properly in
vtls/schannel.c instead.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Since 5017d5ada (polarssl: now require 1.3.0+, 2014-03-17), we require
a newer PolarSSL version. No need to keep code trying to support any
older version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In the ongoing endeavor to abstract out all SSL backend-specific
functionality, this is the next step: Instead of hard-coding how the
different SSL backends access their internal data in getinfo.c, let's
implement backend-specific functions to do that task.
This will also allow for switching SSL backends as a runtime option.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There are convenient no-op versions of the init/cleanup functions now,
no need to define private ones for axTLS.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
These functions are all available via the Curl_ssl struct now, no need
to declare them separately anymore.
As the global declarations are removed, the corresponding function
definitions are marked as file-local. The only two exceptions here are
Curl_mbedtls_shutdown() and Curl_polarssl_shutdown(): only the
declarations were removed, there are no function definitions to mark
file-local.
Please note that Curl_nss_force_init() is *still* declared globally, as
the only SSL backend-specific function, because it was introduced
specifically for the use case where cURL was compiled with
`--without-ssl --with-nss`. For details, see f3b77e561 (http_ntlm: add
support for NSS, 2010-06-27).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The _shutdown() function calls the _session_free() function; While this
is not a problem now (because schannel.h declares both functions), a
patch looming in the immediate future with make all of these functions
file-local.
So let's just move the _session_free() function's definition before it
is called.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The connect_finish() function (like many other functions after it) calls
the Curl_axtls_close() function; While this is not a problem now
(because axtls.h declares the latter function), a patch looming in the
immediate future with make all of these functions file-local.
So let's just move the Curl_axtls_close() function's definition before
it is called.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The entire idea of introducing the Curl_ssl struct to describe SSL
backends is to prepare for choosing the SSL backend at runtime.
To that end, convert all the #ifdef have_curlssl_* style conditionals
to use bit flags instead.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The SHA-256 checksumming is also an SSL backend-specific function.
Let's include it in the struct declaring the functionality of SSL
backends.
In contrast to MD5, there is no fall-back code. To indicate this, the
respective entries are NULL for those backends that offer no support for
SHA-256 checksumming.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The MD5 summing is also an SSL backend-specific function. So let's
include it, offering the previous fall-back code as a separate function
now: Curl_none_md5sum(). To allow for that, the signature had to be
changed so that an error could be returned from the implementation
(Curl_none_md5sum() can run out of memory).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is the first step to unify the SSL backend handling. Now all the
SSL backend-specific functionality is accessed via a global instance of
the Curl_ssl struct.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The idea of introducing the Curl_ssl struct was to unify how the SSL
backends are declared and called. To this end, we now provide an
instance of the Curl_ssl struct for each and every SSL backend.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This new struct is similar in nature to Curl_handler: it will define the
functions and capabilities of all the SSL backends (where Curl_handler
defines the functions and capabilities of protocol handlers).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This patch makes the signature of the _sha256sum() functions consistent
among the SSL backends, in preparation for unifying the way all SSL
backends are accessed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This patch makes the signature of the _data_pending() functions
consistent among the SSL backends, in preparation for unifying the way
all SSL backends are accessed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This patch makes the signature of the _cleanup() functions consistent
among the SSL backends, in preparation for unifying the way all SSL
backends are accessed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
... as the previous fixed length 128 bytes buffer was sometimes too
small.
Fixes#1823Closes#1831
Reported-by: Benjamin Sergeant
Assisted-by: Bill Pyne, Ray Satiro, Nick Zitzmann
Recent changes that replaced CURL_SIZEOF_LONG in the source with
SIZEOF_LONG broke builds that use the premade configuration files and
don't have SIZEOF_LONG defined.
Bug: https://github.com/curl/curl/issues/1816
libidn was replaced with libidn2 last year in configure.
Caveat: libidn2 may depend on a list of further libs.
These can be manually specified via CURL_LDFLAG_EXTRAS.
Closes https://github.com/curl/curl/pull/1815
Recent changes that replaced CURL_SIZEOF_LONG in the source with
SIZEOF_LONG broke builds that use the premade configuration files and
don't have SIZEOF_LONG defined.
Closes https://github.com/curl/curl/pull/1814
Fixes
$ valgrind --leak-check=full ~/install-curl-git/bin/curl tftp://localhost/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaz
==9752== Memcheck, a memory error detector
==9752== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==9752== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==9752== Command: /home/even/install-curl-git/bin/curl tftp://localhost/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaz
==9752==
curl: (71) TFTP file name too long
==9752==
==9752== HEAP SUMMARY:
==9752== 505 bytes in 1 blocks are definitely lost in loss record 11 of 11
==9752== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9752== by 0x4E61CED: Curl_urldecode (in /home/even/install-curl-git/lib/libcurl.so.4.4.0)
==9752== by 0x4E75868: tftp_state_machine (in /home/even/install-curl-git/lib/libcurl.so.4.4.0)
==9752== by 0x4E761B6: tftp_do (in /home/even/install-curl-git/lib/libcurl.so.4.4.0)
==9752== by 0x4E711B6: multi_runsingle (in /home/even/install-curl-git/lib/libcurl.so.4.4.0)
==9752== by 0x4E71D00: curl_multi_perform (in /home/even/install-curl-git/lib/libcurl.so.4.4.0)
==9752== by 0x4E6950D: curl_easy_perform (in /home/even/install-curl-git/lib/libcurl.so.4.4.0)
==9752== by 0x40E0B7: operate_do (in /home/even/install-curl-git/bin/curl)
==9752== by 0x40E849: operate (in /home/even/install-curl-git/bin/curl)
==9752== by 0x402693: main (in /home/even/install-curl-git/bin/curl)
Fixes https://oss-fuzz.com/v2/testcase-detail/5232311106797568
Credit to OSS Fuzz
Closes#1808
Since curl 7.55.0, NetworkManager almost always failed its connectivity
check by timeout. I bisected this to 5113ad04 (http-proxy: do the HTTP
CONNECT process entirely non-blocking).
This patch replaces !Curl_connect_complete with Curl_connect_ongoing,
which returns false if the CONNECT state was left uninitialized and lets
the connection continue.
Closes#1803Fixes#1804
Also-fixed-by: Gergely Nagy
The required low-level logic was already available as part of
`libssh2` (via `LIBSSH2_FLAG_COMPRESS` `libssh2_session_flag()`[1]
option.)
This patch adds the new `libcurl` option `CURLOPT_SSH_COMPRESSION`
(boolean) and the new `curl` command-line option `--compressed-ssh`
to request this `libssh2` feature. To have compression enabled, it
is required that the SSH server supports a (zlib) compatible
compression method and that `libssh2` was built with `zlib` support
enabled.
[1] https://www.libssh2.org/libssh2_session_flag.html
Ref: https://github.com/curl/curl/issues/1732
Closes https://github.com/curl/curl/pull/1735
This change does two things:
1. It un-breaks the build in Xcode 9.0. (Xcode 9.0 is currently
failing trying to compile connectx() in lib/connect.c.)
2. It finally weak-links the connectx() function, and falls back on
connect() when run on older operating systems.
Update the progress timers `t_nslookup`, `t_connect`, `t_appconnect`,
`t_pretransfer`, and `t_starttransfer` to track the total times for
these activities when a redirect is followed. Previously, only the times
for the most recent request would be tracked.
Related changes:
- Rename `Curl_pgrsResetTimesSizes` to `Curl_pgrsResetTransferSizes`
now that the function only resets transfer sizes and no longer
modifies any of the progress timers.
- Add a bool to the `Progress` struct that is used to prevent
double-counting `t_starttransfer` times.
Added test case 1399.
Fixes#522 and Known Bug 1.8
Closes#1602
Reported-by: joshhe on github
Fixes the below leak:
$ valgrind --leak-check=full ~/install-curl-git/bin/curl --proxy "http://a:b@/x" http://127.0.0.1
curl: (5) Couldn't resolve proxy name
==5048==
==5048== HEAP SUMMARY:
==5048== in use at exit: 532 bytes in 12 blocks
==5048== total heap usage: 5,288 allocs, 5,276 frees, 445,271 bytes allocated
==5048==
==5048== 2 bytes in 1 blocks are definitely lost in loss record 1 of 12
==5048== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5048== by 0x4E6CB79: parse_login_details (url.c:5614)
==5048== by 0x4E6BA82: parse_proxy (url.c:5091)
==5048== by 0x4E6C46D: create_conn_helper_init_proxy (url.c:5346)
==5048== by 0x4E6EA18: create_conn (url.c:6498)
==5048== by 0x4E6F9B4: Curl_connect (url.c:6967)
==5048== by 0x4E86D05: multi_runsingle (multi.c:1436)
==5048== by 0x4E88432: curl_multi_perform (multi.c:2160)
==5048== by 0x4E7C515: easy_transfer (easy.c:708)
==5048== by 0x4E7C74A: easy_perform (easy.c:794)
==5048== by 0x4E7C7B1: curl_easy_perform (easy.c:813)
==5048== by 0x414025: operate_do (tool_operate.c:1563)
==5048==
==5048== 2 bytes in 1 blocks are definitely lost in loss record 2 of 12
==5048== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5048== by 0x4E6CBB6: parse_login_details (url.c:5621)
==5048== by 0x4E6BA82: parse_proxy (url.c:5091)
==5048== by 0x4E6C46D: create_conn_helper_init_proxy (url.c:5346)
==5048== by 0x4E6EA18: create_conn (url.c:6498)
==5048== by 0x4E6F9B4: Curl_connect (url.c:6967)
==5048== by 0x4E86D05: multi_runsingle (multi.c:1436)
==5048== by 0x4E88432: curl_multi_perform (multi.c:2160)
==5048== by 0x4E7C515: easy_transfer (easy.c:708)
==5048== by 0x4E7C74A: easy_perform (easy.c:794)
==5048== by 0x4E7C7B1: curl_easy_perform (easy.c:813)
==5048== by 0x414025: operate_do (tool_operate.c:1563)
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2984
Credit to OSS Fuzz for discovery
Closes#1761
... and thereby avoid telling send() to send off more bytes than the
size of the buffer!
CVE-2017-1000100
Bug: https://curl.haxx.se/docs/adv_20170809B.html
Reported-by: Even Rouault
Credit to OSS-Fuzz for the discovery
First: this function is only used in debug-builds and not in
release/real builds. It is used to drive tests using the event-based
API.
A pointer to the local struct is passed to CURLMOPT_TIMERDATA, but the
CURLMOPT_TIMERFUNCTION calback can in fact be called even after this
funtion returns, namely when curl_multi_remove_handle() is called.
Reported-by: Brian Carpenter
When multiple rounds are needed to establish a security context
(usually ntlm), we overwrite old token with a new one without free.
Found by proposed gss tests using stub a gss implementation (by
valgrind error), though I have confirmed the leak with a real
gssapi implementation as well.
Closes https://github.com/curl/curl/pull/1733
clang complains:
vtls/darwinssl.c:40:8: error: extra tokens at end of #endif directive
[-Werror,-Wextra-tokens]
This breaks the darwinssl build on Travis. Fix it by making this token
a comment.
Closes https://github.com/curl/curl/pull/1734
The MSVC warning level defaults to 3 in CMake. Change it to 4, which is
consistent with the Visual Studio and NMake builds. Disable level 4
warning C4127 for the library and additionally C4306 for the test
servers to get a clean CURL_WERROR build as that warning is raised in
some macros in older Visual Studio versions.
Ref: https://github.com/curl/curl/pull/1667#issuecomment-314082794
Closes https://github.com/curl/curl/pull/1711
Use LongToHandle to convert from long to HANDLE in the Win32
implementation.
This should fix the following warning when compiling with
MSVC 11 (2012) in 64-bit mode:
lib\curl_threads.c(113): warning C4306:
'type cast' : conversion from 'long' to 'HANDLE' of greater size
Closes https://github.com/curl/curl/pull/1717
There are some bugs in how timers are managed for a single easy handle
that causes the wrong "next timeout" value to be reported to the
application when a new minimum needs to be recomputed and that new
minimum should be an existing timer that isn't currently set for the
easy handle. When the application drives a set of easy handles via the
`curl_multi_socket_action()` API (for example), it gets told to wait the
wrong amount of time before the next call, which causes requests to
linger for a long time (or, it is my guess, possibly forever).
Bug: https://curl.haxx.se/mail/lib-2017-07/0033.html
The headers of librtmp declare the socket as `int`, and on Windows, that
disagrees with curl_socket_t.
Bug: #1652
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
... to make all libcurl internals able to use the same data types for
the struct members. The timeval struct differs subtly on several
platforms so it makes it cumbersome to use everywhere.
Ref: #1652Closes#1693
... causing a SIGSEGV in showit() in case the handle used to initiate
the connection has already been freed.
This commit fixes a bug introduced in curl-7_19_5-204-g5f0cae803.
Reported-by: Rob Sanders
Bug: https://bugzilla.redhat.com/1436158
This is a follow-up to af02162 which removed (SET_)ERRNO macros. That
commit was an earlier draft that I committed by mistake, which was then
remedied by a5834e5 and e909de6, and now this commit. With this commit
there is now no difference between the current code and the changes that
were approved in the final draft.
Thanks-to: Max Dymond, Marcel Raad, Daniel Stenberg, Gisle Vanem
Ref: https://github.com/curl/curl/pull/1589
