Introduce `toolx_ftruncate()` macro and map it to existing replacements
for non-mingw-w64 Windows and DJGPP, or to `ftruncate` otherwise.
Follow-up to 6041b9b11b#21109Closes#21130
New connection filter `cf-dns` that manages DNS queries. If hands
out addresses and HTTPS-RR records to anyone interested. Used by
HTTPS and IP happy eyeballing.
Information may become available *before* the libcurl "dns entry"
is complete, e.g. all queries have been answered. The cf-ip-happy
filter uses this information to start connection attempts as soon
as the first address is available.
The multi MSTATE_RESOLVING was removed. A new connection always
goes to MSTATE_CONNECTING. The connectdata bit `dns_resolved`
indicates when DNS information is complete. This is used for
error reporting and starting the progress meter.
Removed dns entries `data->state.dns[i]`, as the `cf-dns` filter
now keeps the reference now.
Many minor tweaks for making this work and pass address information
around safely.
Closes#21027
It was wrongly previously only used in debug code for event based
transfer and not in the "normal" parallel transfer case.
Follow-up to 4654493fedCloses#21147
This warning was created at a time when all backends for HTTP/3 were
experimental. Since there are now non-experimental backends this warning
is incorrect in some cases and was already handled by backends that were
added to the experimental list.
Follow-up to 0535f6ec71Closes#21139
By moving the coexist workaround from vtls/openssl.c to vtls/openssl.h.
This way it also applies to vtls.c (and possibly other sources including
`vtls/openssl.h`), which may need it in unity builds before BoringSSL
header `openssl/ssl.h` pulling in the conflicting symbols and causing
conflicts otherwise.
Seen with build config:
```
-DCURL_USE_SCHANNEL=ON -DCURL_USE_OPENSSL=ON
-DCMAKE_UNITY_BUILD=ON -DCMAKE_UNITY_BUILD_BATCH_SIZE=30
```
Fixing:
```
In file included from _cm-win-boringssl/lib/CMakeFiles/libcurl_object.dir/Unity/unity_5_c.c:7:
In file included from lib/vtls/vtls.c:54:
In file included from lib/vtls/openssl.h:33:
In file included from /path/to/boringssl/_x64-win-ucrt/usr/include/openssl/opensslv.h:18:
In file included from /path/to/boringssl/_x64-win-ucrt/usr/include/openssl/crypto.h:18:
/path/to/boringssl/_x64-win-ucrt/usr/include/openssl/base.h:293:29: error: expected ')'
293 | typedef struct X509_name_st X509_NAME;
| ^
/path/to/llvm-mingw/x86_64-w64-mingw32/include/wincrypt.h:1515:29: note: expanded from macro 'X509_NAME'
1515 | #define X509_NAME ((LPCSTR) 7)
| ^
[...]
```
Ref: 2a92c39a21#20567Closes#21136
- update `filelock` from 3.24.3 to 3.25.2
- update `ruff` from 0.15.2 to 0.15.7
- update `cryptography` from 46.0.5 to 46.0.6 (CVE-2026-34073)
Closes#21138
The myssh_in_SFTP_READDIR_BOTTOM() function would not store the error
code correctly thus it could be ignored and missed when an error was
returned at that particular moment.
Follow-up to 3c26e6a896
Found by Codex Security
Closes#21122
non-HTTP protocols no longer retry after connection reuse failures
because multi_follow() now requires a handler->follow callback that is
NULL for those protocols. Provide a fallback for plain retries.
Follow-up to 1213c31272
Spotted by Codex Security
Closes#21121
When assembling the URL of a pushed resource over a not-secured
connection, require the scheme to be known and not secure.
Reported-by: xkilua on hackerone
Closes#21113
```
lib/vtls/openssl.c:4238:22: error: ‘SSL_R_SSLV3_ALERT_CERTIFICATE_EXPIRED’ undeclared (first use in this function); did you mean ‘SSL_R_TLS_ALERT_CERTIFICATE_EXPIRED’?
4238 | (reason == SSL_R_SSLV3_ALERT_CERTIFICATE_EXPIRED))) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| SSL_R_TLS_ALERT_CERTIFICATE_EXPIRED
lib/vtls/openssl.c:4238:22: note: each undeclared identifier is reported only once for each function it appears in
```
Ref: https://github.com/curl/curl/actions/runs/23641366299/job/68863072427#step:24:189
Cherry-picked from #21118Closes#21119
memory allocated by libcurl must be freed with curl_free() and vice versa,
memory allocated by the tool itself must be freed with curlx_free().
- dynbuf: free libcurl data with curl_free()
- tool_operate: make sure we get URL using the right memory
- tool_operhlp: free libcurl memory with curl_free()
- tool_operate: free curl_maprintf() pointer with curl_free
- var: data from curlx_base64_decode needs curlx_free
- tool_operate: fix memory juggling in etag handling
- tool_cb_hdr: fix memory area mixups
- tool_operate: another mixup in etag management
- tool_cb_hdr: more memory mixup fixes
- tool_cfgable.c: document some details
- tool_help: show global-mem-debug in -V output
Closes#21099
Build with "configure --enable-init-mem-debug" to make the tool use
curl_global_init_mem() and a set of private memory funtion callbacks for
libcurl's memory management.
Using this setup, memory mixups in tool code is more likely to cause
crashes and thus get discovered while running tests.
This curl_global_init_mem debug mode can only be done when building
libcurl shared (not static) and without debugging enabled - since it
needs to use the custom memory funtion callbacks.
Closes#21099
Systems without it need to provide a custom alternative just like we
have have for Windows. This adds an MSDOS version that fails if trying
to truncate a too large file.
Closes#21109
It's been going on for almost a year, chances seem slim to have this
fixed upstream.
The observed issue is that on GitHub-supplied CI runner images,
sometimes, `apt-get install` using the stock distro server
`http://azure.archive.ubuntu.com/ubuntu` sees extreme slowness while
downloading data, then reaching the job timeout and aborting, making CI
red and necessitating a manual restart of the failed job(s).
In majority of cases the install step takes no longer than 8-40 seconds
(download + install), while in the failing case it takes 10-20+ minutes
just to download.
Earlier I slimmed down installs to avoid unnecessary packages, which
mitigated, but did not completely fix the issue.
Example:
https://github.com/curl/curl/actions/runs/23599596928/job/68725576899?pr=21105
Follow-up to 0455d8772a#18509Closes#21107
To avoid rate limits when accessing GH APIs during the build.
Aiming to avoid (while trying to retrieve a file timestamp):
```
++ [[ 2026-02-11-1a84aee6387d2f9c9531c655edeea4a80aa0fcfa =~ (.+)-([a-f0-9]{40,}) ]]
++ ver=2026-02-11
++ commit=1a84aee6387d2f9c9531c655edeea4a80aa0fcfa
++ set +x
curl: (22) The requested URL returned error: 403
curl: (22) The requested URL returned error: 403
curl: (22) The requested URL returned error: 403
curl: (22) The requested URL returned error: 403
[...]
```
Ref: https://github.com/curl/curl/actions/runs/23598912140/job/68723120977?pr=21104
Follow-up to:
a26898fe4817f2fb3ead6dd6e47e98b461404b5aCloses#21105
Replacing the OpenSSL-like compatibility interface, and syncing with other
hashes, when building with wolfSSL.
Also: stop stomping on OpenSSL public MD4 symbols. This makes the wolfSSL
coexist workaround unnecessary, while also syncing up with MD5 sources.
After this patch the only remaining reference to wolfSSL's OpenSSL
compatibility layer is in `lib/curl_ntlm_core.c`.
Closes#21093
Maximum filename length 64, of which 48 maximum for the filename part.
Allowed characters: `A-Za-z0-9/._-`.
Also:
- rename a file to pass the check.
- init max constants outside the loop.
- minor fix to an error message.
Follow-up to 62d77b12fc#21087Closes#21095
The refactoring in #20832 introduced some inconsistencies between
windows and posix handling, pointed out by reviews. Fix them:
- rename `wait_on_nop` back to `extrawait` as it was called before
- use multi_timeout() to shorten the user supplied timeout for
both windows/posix in the same way
- remove the extra multi_timeout() check in the posix function
- Add the multi's wakeup socket for monitoring only when there
are other sockets to poll on or when the caller wants the
extra waiting time.
Closes#21072
Add test1715 to check proper handling of chunked transfer
encoding in CONNECT responses. Change proxy error code from
56 (RECV_ERROR) for everything to 7 (COULDNT_CONNECT) when
the server response could be read successfully, but establishing
the connection is not possible (http status code wrong).
Adapt several test expectations from 56 to 7.
Closes#21084
