Bump the requirement to v3.6.3, which means we can remove the final
ifdef guard and all the builds have TLS 1.3 support.
It was released over 7 years ago, with 2 new feature releases since
then and dozen of bugfix releases in the 3.6 branch.
The oldest distributions we target Ubuntu 20.04 and Debian Bullseye,
have 3.6.13 and 3.7.1 respectively.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Bump the requirement to v7.68.0, which means we can remove ~70% of the
ifdef guards. It was released over 5 years ago, with 30+ new curl
releases since then and dozens of CVEs fixed.
The oldest distributions we target Ubuntu 20.04 and Debian Bullseye,
have 7.68.0 and 7.74.0 respectively.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This fixes this warning with clang:
src/core/core-url.c:1017:5: warning: call to '_curl_easy_setopt_err_long' declared with 'warning' attribute: curl_easy_setopt expects a long argument [-Wattribute-warning]
1017 | curl_easy_setopt (curl, CURLOPT_PROXYPORT,
| ^
/usr/include/x86_64-linux-gnu/curl/typecheck-gcc.h:50:15: note: expanded from macro 'curl_easy_setopt'
50 | _curl_easy_setopt_err_long(); \
| ^
When invalid data is received (not an HTTP request), client->http_req->method
is NULL, so we have to check it's not NULL before comparing it to the supported
methods.
This fixes a regression introduced in commit
93ec10b563.
This fixes the API probe made by schemathesis, so it detects immediately that
such NULL byte is not allowed by WeeChat, instead of timing out after 10
seconds:
✅ API capabilities:
Supports NULL byte in headers: ✘
Previous behavior was to reverse the partial completion, which was confusing
when option like weechat.completion.partial_completion_command_arg was enabled
as well.
This reverts commit e64ab3c675.
This was causing incorrect conversion of strings "0x..." to pointers on systems
like Solaris/illumos.
And as a side effect, buffers were sometimes empty in weechat relay clients
like glowing-bear.
Now the function utf8_next_char with an empty string returns NULL instead of
the next char, which is most of the time after an allocated buffer.
And the function utf8_char_size with an empty string now returns 0 instead of
1.
This indirectly fixes a buffer overflow in function eval_string_range_chars
when the input string is empty (for example when doing `/eval -n ${chars:}`).
Emil Velikov