Viktor Szakats [Tue, 30 Dec 2025 10:21:05 +0000 (11:21 +0100)]
tool: improve error/warning messages when output filename sanitization fails
On MS-DOS (OOM and bad filename) and Windows (OOM only).
Given the rarity of both platform and error, we make a compromise and
return an unrelated libcurl error (43) in case of a bad output filename
on MS-DOS.
After:
```
$ CURL_FN_SANITIZE_OOM=1 wine curl.exe https://curl.se/ --output out.txt
curl: (27) Out of memory
$ CURL_FN_SANITIZE_BAD=1 wine curl.exe https://curl.se/ --output out.txt
Warning: bad output filename
curl: (43) A libcurl function was given a bad argument
$ CURL_FN_SANITIZE_OOM=1 wine curl.exe https://curl.se/index.html --globoff -O
curl: (27) Out of memory
$ CURL_FN_SANITIZE_BAD=1 wine curl.exe https://curl.se/index.html --globoff -O
curl: bad output filename
curl: (43) A libcurl function was given a bad argument
```
Before:
```
$ CURL_FN_SANITIZE_OOM=1 wine curl.exe https://curl.se/ --output out.txt
Warning: bad output glob
curl: (27) Out of memory
$ CURL_FN_SANITIZE_BAD=1 wine curl.exe https://curl.se/ --output out.txt
Warning: bad output glob
curl: (3) URL using bad/illegal format or missing URL
$ CURL_FN_SANITIZE_OOM=1 wine curl.exe https://curl.se/index.html --globoff -O
curl: Failed to extract a filename from the URL to use for storage
curl: (27) Out of memory
$ CURL_FN_SANITIZE_BAD=1 wine curl.exe https://curl.se/index.html --globoff -O
curl: Failed to extract a filename from the URL to use for storage
curl: (3) URL using bad/illegal format or missing URL
```
Viktor Szakats [Fri, 9 Jan 2026 14:51:04 +0000 (15:51 +0100)]
GHA: switch 12 Linux jobs to arm64
More cost-effective and seems as fast or faster than Intel.
In particular, valgrind seems to be almost 2x fast. So fast the job pair
could fit under 10 minutes if merged again (but would be the longest in
GHA/Linux.)
Installing packages is slightly slower. The package repo is Ubuntu's
which is slower than the Azure mirror used on Intel (unless Azure is
broken, which happened a lot last year).
To add to more jobs, the locally built deps also need to be migrated.
Also:
- add workaround for failing sshd server on Linux arm runners, caused by
world-writable `HOME` directory.
Viktor Szakats [Thu, 8 Jan 2026 13:28:02 +0000 (14:28 +0100)]
cmake: silence useless compiler warnings triggered by the FASTBuild generator
Silencing all of these:
```
11>/tmp/_fbuild.tmp/0x0752c383/core_2/70816E19/krb5_sspi.c:1:5: error: this style of line directive is a GNU extension [-Werror,-Wgnu-line-marker]
1 | # 1 "<built-in>"
| ^
/path/to/curl/lib/vauth/krb5_sspi.c:29:6: error: this style of line directive is a GNU extension [-Werror,-Wgnu-line-marker]
29 | # 26 "/path/to/curl/lib/vauth/krb5_sspi.c"
| ^
[...]
```
FASTBuild is slightly faster than Ninja in basic (single-machine, build
from scratch) cases (and can be more faster in other build cases). It
doesn't support unity builds. Maybe it can bring slightly better
performance to non-unity cmake CI jobs, in jobs having an 'install
prereq' phase already, and installing the fastbuild package being faster
than this gain. It overall seems marginal if any in curl CI. At least
for now. But it doesn't hurt if it works, and may be useful for some.
Requires CMake 4.2+.
That said this workaround may have a better place within CMake.
Stefan Eissing [Fri, 9 Jan 2026 14:23:36 +0000 (15:23 +0100)]
pytest: bump quiche version check update
Since the Lazy Lucas did not manage to get the fix merged in 0.24.7,
increase the pytest version check number in the hope that it will happen
in the next release.
Daniel Stenberg [Thu, 8 Jan 2026 22:57:58 +0000 (23:57 +0100)]
urldata: convert 'long' fields to fixed variable types
Makes sure they work identically cross-platform, as long varies in size
between Windows vs non-Windows. Makes Curl_easy 16 bytes smaller on 64
bit Linux.
This reduces support for the RTSP cseq counters to 32 bit (down from 63
bit previously on 64 bit non-Windows), but it is probably safe.
Implementations probably rarely support anything above 32 bits anyway
and this is how curl has worked on Windows since always.
There is now only one 'long' left in urldata.h (in the ssl_config_data
struct). That field, certverifyresult, is used to store the response
code from TLS backend code and in the OpenSSL case that function returns
an actual 'long'.
Stefan Eissing [Thu, 8 Jan 2026 10:19:39 +0000 (11:19 +0100)]
ngtcp2: stabilize recv
When receiving on a stream that already failed or has already been closed,
return the matching error code without touching the connection. In case
the connection shows errors, e.g. the server closed, those errors should
not have impact on an already failed/closed stream.
This might mitigate flakiness in pytest 07_13 where unexpected errors
occur after a successful upload.
Daniel Stenberg [Wed, 7 Jan 2026 13:58:17 +0000 (14:58 +0100)]
urldata: switch to uint* types more widely
In particular, it turns 'unsigned long' into 'uint32_t' since the code
needs to build and run just as fine on Windows which has 32 bit longs,
so we know the code works with 32 bit field versions.
This makes Curl_easy 56 bytes smaller on my 64 bit Linux (maximized
build).
Daniel Stenberg [Wed, 7 Jan 2026 21:21:40 +0000 (22:21 +0100)]
lib: remove uses of PRIu32 by adding "hack" for DJGPP
Avoid using PRIu32 and PRId32 in product source code. We don't need it.
It reduces readability. It is also inconsistent since unsigned int has
the same size and does not require the define.
DJGPP warns about using %u for uint32_t by default because it seems to
typedef it to unsigned long instead of unsigned int. Which even that is
annoying since long and int are both 32 bit on this platform.
We use our own *printf() implementation and we know this is safe.
This work-around defines uint32_t for DJGPP into unsigned int to avoid
the warnings and thus the need to use PRIu32 and PRId32.
Viktor Szakats [Tue, 6 Jan 2026 22:50:48 +0000 (23:50 +0100)]
lib: sync printf masks with `uint32_t` types
Also adjust a printf mask for signedness.
Fixing with MS-DOS DJGPP gcc 12.2.0:
```
lib/conncache.c:612:22: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:394:22: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:520:20: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:520:20: error: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:611:20: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:614:22: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:887:20: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:887:20: error: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:2719:26: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:2725:30: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:2729:28: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:3126:34: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:3348:34: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi.c:3991:28: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi_ev.c:343:24: error: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi_ev.c:413:24: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi_ev.c:584:36: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi_ntfy.c:113:34: error: format '%d' expects argument of type 'int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi_ntfy.c:113:34: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'}
lib/multi_ntfy.c:171:22: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'}
lib/url.c:883:22: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
lib/url.c:889:22: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned int'}
```
Viktor Szakats [Tue, 6 Jan 2026 18:34:53 +0000 (19:34 +0100)]
tool_urlglob: fix propagating OOM error from `sanitize_file_name()`
Make sure to convert a low-level OOM error code a libcurl one, to make
the curl tool to display an accurate error code and messages. On Windows
and MS-DOS.
Improving:
```
$ CURL_FN_SANITIZE_OOM=1 wine curl.exe https://curl.se/ --output out.txt
[...]
curl: (3) URL using bad/illegal format or missing URL
```
to:
```
[...]
curl: (27) Out of memory
```
Viktor Szakats [Mon, 5 Jan 2026 10:04:10 +0000 (11:04 +0100)]
curlx_win32_fopen: use `_fsopen()`/`_wfsopen()` with `_SH_DENYNO`
Replacing `fopen_s()`/`_wfopen_s()`, to allow customizing share mode,
and keep the sharing mode as was with `fopen()`/`_wopen()` earlier and
as used in `_sopen_s()`/`_wsopen_s()`.
The replaced functions used `_SH_SECURE` internally. Otherwise they are
identical to the replacements.
Andrew [Mon, 5 Jan 2026 18:00:20 +0000 (18:00 +0000)]
ldap: fix `Curl_ldap_version()` for IBMi/OS400
- `LDAP_OPT_SUCCESS` (== 0) is missing from some LDAP implementations
and documented to use `LDAP_SUCCESS` (== 0) instead. Use literal zero
to avoid macro name differences.
- fix freeing `LDAP_OPT_API_INFO` buffers:
- docs suggest `ldapai_vendor_name` on IBMi is `const char *`.
Nothing in docs says it need to be freed.
- `ldapai_extensions` need to be freed, according to docs.
However, on IBMi there is `ldap_value_free()` function for it.
Ref: https://www.ibm.com/docs/en/svd/10.0.3?topic=settings-ldap-opt-api-info
Fixing, on OS400 (V7R4M0):
```
CZM1003: LDAP__819.c, 1028.56: CZM0045(30) Undeclared identifier LDAP_OPT_SUCCESS.
CZM1003: LDAP__819.c, 1036.21: CZM0280(30) Function argument assignment between types "char*" and "const char*" is not allowed.
CZM1001: LDAP__819.c, 1037.5: CZM0304(10) No function prototype given for "ber_memvfree".
...
CZS0601: Module LDAP is not created because statement errors occurred.
```
Viktor Szakats [Mon, 5 Jan 2026 13:08:58 +0000 (14:08 +0100)]
GHA/macos: drop compiler matrix for macos jobs
To reduce the number of jobs, and the time spent running macos runners.
The curl codebase has just a few Apple-specific parts, and they remain
well-covered after this patch.
Makes the number of jobs 24, down from 32.
Perhaps more jobs could be merged or dropped, and CPU use reduced by
moving some to cmake. Unique, but not Apple-specific jobs may also be
moved to Linux.
Daniel Stenberg [Sat, 3 Jan 2026 11:16:06 +0000 (12:16 +0100)]
progress: narrower time display, multiple fixes
- Each time field is now 7 characters wide, so that the total width
never exceeds 79 columns so that it works correctly also in Windows
terminals. The title lines are adjusted accordingly.
This is accomplished by using h:mm:ss style up to 10 hours, and for
longer periods switch to "nnX nnY" style output. For hours, days,
months and years.
For less than one hour, the hour field is now dropped.
When no time info is provided, the field is now space-only. No more
`-:--:--`.
Also fixed the output for really long times which previously was
completely broken. The largest time now shows as ">99999y". (Becase
I can't figure out a better way).
- For sizes, the widths are now properly fixed to 6 characters. When
displaying a unit with less than 3 digits, it shows two decimal
precision like "16777215 => 15.99M" and one decmal otherwise: "262143
=> 255.9k"
Also fixes the decimal math. 131071 is 127.9k, which it previously did
not show.
- The time and size field outputs are now properly verified in test
1636.
Viktor Szakats [Sun, 4 Jan 2026 00:15:50 +0000 (01:15 +0100)]
GHA/macos: reduce number of combination jobs
- drop autotools (except one) from combination jobs.
They seem to add little value over cmake ones, yet take a lot of time
even after restricting them to shared libs.
20-25s to install autotools via Homebrew, for each 11 jobs. autoreconf
taking 10s, configure 25s, build 30-35s. A total of 1m30s to 1m45s per
job. Sometimes jumping up to 2-4 minutes.
Compare this to 20-25s total job times with cmake.
Keep one job with an indentical cmake pair to help detecting
build-tool-specific fallouts.
- drop more combination jobs.
To avoid overlap with main build jobs.
Reducing number of jobs to 9, from 22 (-13),
total job time to 5.5 minutes, from 25 (-20m).
Considering the small amount of Apple-specific code in curl since
dropping Secure Transport, and that most combination issue were in
the toolchains, not curl, there is likely more room to avoid wasting
cycles (at 41 macOS + 3 iOS jobs after this patch).
Viktor Szakats [Sat, 3 Jan 2026 17:44:00 +0000 (18:44 +0100)]
servers.pm: say the protocol when http server failed to start
To serve as possibly more signal to see when/why the http server fails
to start in some random cases (on Windows).
Seen it happen in the 'mingw, CM clang-x86_64 gnutls libss' CI job:
https://github.com/curl/curl/pull/20163#issuecomment-3705572750
https://github.com/curl/curl/pull/20163#issuecomment-3707231458
Stefan Eissing [Fri, 2 Jan 2026 13:08:21 +0000 (14:08 +0100)]
pytest: test 16_01 stabilize
When checking the reported times of a transfer, do not exptect
the 'queue' time to be in any relation to others. 'queue' uses its own
start timestamp and the reported duration is thereofore independant.
Stefan Eissing [Fri, 2 Jan 2026 13:23:21 +0000 (14:23 +0100)]
pytest: test 07_22 stabilize
Do not generate a 400 response code, but use a 200 one. The upload needs
to fail on sending, not on seeing a 400 response. Seeing a 400 before
the sending fails (when CI timings shift) will expose the wrong error
code.
Stefan Eissing [Fri, 2 Jan 2026 11:46:35 +0000 (12:46 +0100)]
pytest: test 07_70 stabilize (curl_ngtcp2)
We recently allowed a larger send buffer in ngtcp2 streams. This allowed
curl to send more early data then previously when the server was slow in
performing the handshake. This led to flaky test failures when the
amount of early data was larger than expected.
Change test expectations to allow for varying amount of early data.
Stefan Eissing [Fri, 2 Jan 2026 12:14:12 +0000 (13:14 +0100)]
pytest: test 03_02 stabilize (curl_ngtcp2)
The special handling for draining server connections during a connect
attempt was only done on CURLE_RECV_ERROR. But it may also happen when
ngtcp2 errors on writing data. Check for CURLE_SEND_ERROR also.
Viktor Szakats [Fri, 2 Jan 2026 21:50:34 +0000 (22:50 +0100)]
GHA/windows: reduce workflow timeouts
From 15 to 10 minutes.
To reduce the idle wait for hung jobs from 20 to 15 minutes (hopefully),
so that the failed just can be restarted manually eariler. It appears
that GitHub Actions notices a hung job 5 minutes past the workflow
timeout (reason undiscovered).
Also: Leave extra time for torture and arm64 jobs.
Viktor Szakats [Fri, 2 Jan 2026 16:45:09 +0000 (17:45 +0100)]
GHA: disable autotools static libcurl in many jobs
To avoid building libcurl in both static and shared flavor by default.
It results in 1.5-2.x speed-up for the curl build step in most jobs.
Saving a total of 6-7 minutes. In the Cygwin job alone it saves 1-1.5m.
Also:
- enable static + shared in a Windows job to keep testing this combo.
Viktor Szakats [Fri, 2 Jan 2026 02:13:32 +0000 (03:13 +0100)]
GHA/linux: split valgrind jobs to job-pairs for parallelism, to finish in 10m
To make CI turnaround time shorter, by cutting the longest running jobs.
After this patch all jobs should finish around 10-11 minutes. Down from
15-16 minutes before this patch.
Suggested-by: Stefan Eissing
The fuzzing workflow is now the slowest (with a 7-minute startup time
needed to build deps from source on each run), followed by macOS
and Windows torture tests (both split in two now). Without fuzzing, it's
under 10 minutes.
Notes:
- an extra cost with job-pairs is installing prereqs,
configuring/building curl and tests twice. GitHub doesn't support
making a matrix job a prereq for another workflow that may fix this:
https://github.com/orgs/community/discussions/42335
This overhead is significant on Windows: 11m20 -> 9m20 + 8m40
- job-pairs are annoying to maintain and keep in sync.
- splitting tests into halves is a manual process and needs to be
revisited from time to time. Possibly something to automate with
a runtests option, e.g. with `1 of 50%` and `2 of 50%`?
Also:
- split torture tests in two equal pieces, replacing the `FTP` + `!FTP`
split used earlier.
Viktor Szakats [Fri, 2 Jan 2026 10:03:12 +0000 (11:03 +0100)]
GHA/linux: switch scan-build jobs to cmake (for 2x perf)
Somewhat unexpectedly, switching autotools jobs to identical (non-unity,
non-debug, same options) cmake ones, makes them complete 2x faster.
Most of it comes from cmake building shared libcurl only, while autotools
was using defaults and building both, in two separate passes. Thers is
about a minute (per job) of gain due to other reasons.
After:
MultiSSL: 4m52s: https://github.com/curl/curl/actions/runs/20658343323/job/59315501903
H3: 4m7s: https://github.com/curl/curl/actions/runs/20658343323/job/59315501918
H3: 5m4s: https://github.com/curl/curl/actions/runs/20659294959/job/59318215987 (autotools shared only, for comparison, not merged)
Also:
- drop building examples with scan-build in the second (shorter) job.
This offers no extra coverage over the long job that has both GnuTLS
and OpenSSL. Saving an extra ~30s.
Viktor Szakats [Wed, 31 Dec 2025 17:15:17 +0000 (18:15 +0100)]
pytest: replace allowlist with feature check to enable OCSP test 17_08
Add a `cert-status` feature flag to `curlinfo`, based on the conditions
used in `lib/vtls` sources.
To:
- fix disabling this test when using OpenSSL (or fork) built with
the `no-ocsp` option.
- enable this test for AWS-LC in CI.
Note:
- BoringSSL (and quiche) has OSCP disabled by default.
- MultiSSL dynamic selection continues to confuse this test.
(To fix it, support would need to be detected by querying libcurl
via curl. Probably overkill given that OCSP is on its way out.)
dependabot[bot] [Thu, 1 Jan 2026 14:06:15 +0000 (14:06 +0000)]
GHA: bump gha-dependencies
- update `github/codeql-action` from 4.31.8 to 4.31.9
- update `cross-platform-actions/action` from 0.30.0 to 0.32.0
- support for OmniOS and FreeBSD 15.0
- releases are now immutable