- GHA/windows: bump dl-mingw job from gcc 15 to 16.
- multi: silence warning while building libcurlu:
```
In function 'multi_ischanged',
inlined from 'multi_socket.isra' at D:/a/curl/curl/lib/multi.c:3282:6:
D:/a/curl/curl/lib/multi.c:1710:17: error: null pointer dereference [-Werror=null-dereference]
1710 | bool retval = (bool)multi->recheckstate;
| ^~~~~~~~~~~~~~~~~~~~~~~~~
D:/a/curl/curl/lib/multi.c:1712:25: error: null pointer dereference [-Werror=null-dereference]
1712 | multi->recheckstate = FALSE;
| ^
```
Ref: https://github.com/curl/curl/actions/runs/26217071531/job/77142119137?pr=21707
- multi: silence another `-Wnull-dereference`, popping up in libcurl
with gcc 13 after the previous silencing:
```
In function 'Curl_multi_xfers_running',
inlined from 'multi_socket.isra' at ../../lib/multi.c:3292:28:
../../lib/multi.c:4132:15: error: null pointer dereference [-Werror=null-dereference]
4132 | return multi->xfers_alive;
| ~~~~~^~~~~~~~~~~~~
```
Ref: https://github.com/curl/curl/actions/runs/26218822231/job/77148186045
- multi: also add `DEBUGASSERT(multi)` to the two updated functions.
Closes#21707
- bump cross-platform-actions to v1.1.0.
Ref: https://github.com/cross-platform-actions/action/releases/tag/v1.1.0
- merge BSD jobs into a single matrix.
- split BSD jobs into build steps as used for other platforms.
A new feature of cross-platform-actions v1.1.0.
- sync BSD build steps with other platforms.
- add DragonFlyBSD and MidnightBSD to the BSD matrix.
New features of cross-platform-actions v1.1.0.
MidnightBSD uses GnuTLS to add variation, also the preinstalled
OpenSSL is too old (v1.1.1w) for curl.
Stick with autotools for DragonFlyBSD; I could not figure out how
to install cmake.
Refs:
https://en.wikipedia.org/wiki/DragonFly_BSDhttps://en.wikipedia.org/wiki/MidnightBSD
- bump Intel FreeBSD jobs from v14.3 to v15.0.
- fix to show `gcc` in the NetBSD job name.
All these saved 50 lines of YAML. The two new jobs take 2m15s each. The
bump to FreeBSD 15 needs and extra minute in total.
Note, the DragonFlyBSD job seems to have reliability issues. If it
remains an issue, I'll comment it out or delete it in a future commit.
Closes#21681
Also fix fallouts found.
Windows clang-tidy CI job is a little pickier than I'd prefer due to the
`_CURL_TESTS_CONCAT=ON` option used there, and all macros considered
local, thus checked by the compiler. Upside: it revealed macro usage
dynamics in tests. If too annoying, `first.h` may be opted-out from the
concat logic. Some macros may also be deleted instead of `#if 0`-ing.
Follow-up to e0e56e9ae4#21550
Follow-up to 5fa5cb3825#20593Closes#21554
- update action `actions/cache` from 5.0.4 to 5.0.5
- update action `actions/upload-artifact` from 7.0.0 to 7.0.1
- update action `github/codeql-action` from 4.32.4 to 4.35.2
- update action `msys2/setup-msys2` from 2.31.0 to 2.31.1
- update pip `filelock` from 3.25.2 to 3.29.0
- update pip `impacket` to 0.13.0
- update pip `ruff` from 0.15.10 to 0.15.12
Closes#21483Closes#21482
Necessary when the libssh2/libssh client library does not support KEX
algos offered by default by the OpenSSH server. E.g. libssh2 with WinCNG
combined with OpenSSH 10+.
Also: use this option in GHA/windows.
Follow-up to 3b8bb1a86a#21219
Follow-up to c98d0a2e9a#21220Closes#21438
Due to year-long unreliability.
The default Ubuntu mirror works as fast as the Azure one when it's
working at its normal speed. And has HTTPS.
Also:
- replac the retry hack that turn out to not solve the problem.
- add timeouts to each download step to catch slowness early.
Follow-up to a5838847c4#21181
Follow-up to 5172ba5475#21107Closes#21414
`ssh-keygen -t ed25519` does not support PEM key format, and it
defaults to `RFC4716` which is what we want.
It affected GHA/windows tests that explicitly used ed25519 keys.
Also:
- GHA/windows: bump minimums to hopefully catch this early next time.
1701a8319e#21353
- merge two Perl lines.
Reported-by: herbenderbler on github
Fixes#21360
Follow-up to acda4eae5e#21223Closes#21374
via env `CURL_TEST_SSH_KEYALGO`, `rsa` (default), `ecdsa`, `ed25519`.
To ease debugging and testing and to make these code paths more
universal.
Closes#21223
libssh 0.12.0 on Windows 64-bit Intel fails to connect to sshd (with SSH
state 30) when using the mlkem768x25519-sha256 KEX. (32-bit Intel, ARM64
and tested non-Windows platforms work fine.) Fix by disabling this KEX
for the libssh job.
I do not recommend libssh on Windows due to bugs an insecure behavior.
Also:
- fix libssh TFLAGS condition for mingw-w64.
Follow-up to e127f8ce84#21204
Follow-up to fcf946e846#21195Closes#21199
- use it in a mingw-w64 job.
- add support for native ARM64 binaries.
- add ability to use built-in OpenSSH server in mingw-w64 jobs.
Cherry-picked from #21199Closes#21219
Bumping `msys2/setup-msys2` from 2.30.0 to 2.31.0 also brought libssh
0.12.0 (after 0.11.3). libssh has been long known for loading OpenSSH
configuration from disk insecurely on Windows. 0.12.0 brings some fixes
to this (CVE-2025-14821), which in turn may be changing its behavior on
the default GH Windows runner to fail all curl SCP/SFTP tests.
Detecting what is the exact root cause, then defining exact runtime
conditions for it is difficult and fragile. Same for changing these
libssh defaults (if at all possible.)
But, since configuration loading remains insecure and broken on Windows
even after the mitigations made by 0.12.0 [0], this patch removes libssh
from the Windows CI job using it previously.
If someone figures out how to run in CI, it can be readded, though in
general, using libssh on Windows seems to be less than ideal.
[0] 0e4bd38a5b/libssh.sh (L11-L94)
Refs:
https://www.libssh.org/2026/02/10/libssh-0-12-0-and-0-11-4-security-releases/91382507d5#21199 (unsuccessful fix attempts)
Bug: https://github.com/curl/curl/pull/21195#issuecomment-4173085194
Follow-up to fcf946e846#21195Closes#21204
- update `actions/cache` from 5.0.3 to 5.0.4
- update `actions/download-artifact` from 7.0.0 to 8.0.1
- update `actions/upload-artifact` from 6.0.0 to 7.0.0
- update `msys2/setup-msys2` from 2.30.0 to 2.31.0
- update pip `ruff` from 0.15.7 to 0.15.8
Closes#21195Closes#21197
- fail if all retries failed.
- run `dpkg --configure -a` after an aborted slow attempt.
```
Selecting previously unselected package libsys-hostname-long-perl.
Error: slow server, retry
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
[...]
```
Bug: https://github.com/curl/curl/pull/21107#issuecomment-4163506100
Follow-up to 5172ba5475#21107Closes#21181
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
Verify if lines are not longer than 192 characters. Also verify if lines
have less than 79 repeat spaces (and fix one fallout).
To improve readability by avoiding long lines and to prevent adding
overly long lines with text that may go unnoticed in an editor or diff
viewer.
In addition to pre-existing line length limits: 79 for C, 132 for CMake
sources.
Also:
- spacecheck: fix/harden allowlist regexes.
- spacecheck: tidy-up quotes and simplify escaping.
- spacecheck: allow folding strings with repeat spaces.
- GHA: fix a suppressed shellcheck warning.
- GHA/macos: simplify by dropping brew bundle.
- test1119.pl: precompile a regex.
- FAQ.md: delete very long link to a Windows 7/2008 support article
that's lost it relevance.
Closes#21087
To avoid potential warning with autotools when using `CFLAGS`. Existing
jobs are not affected.
Also:
- drop a redundant `export`.
- ensure not to overwrite per-job options with UWP ones.
Closes#20857
- update action `actions/cache` from 5.0.1 to 5.0.3
- update action `github/codeql-action` from 4.31.9 to 4.32.4
- update pip `filelock` from 3.20.3 to 3.24.3
- update pip `ruff` from 0.14.14 to 0.15.2
Closes#20782Closes#20783
Adds 50 seconds to the 5m long build step. Also more prerequisites to
install, with no apparent effect on step time.
Follow-up to 9b52d516bb#20732Closes#20775
Tests are build in "unity"-style, by including sources into an umbrella
C files (similar to how CMake unity works). This does not play well with
clang-tidy, which seems to unconditionally ignore C sources included
like this. To fix it, curl's CMake implements a manual clang-tidy
support for tests, which compiles sources one-by-one, while also making
sure sources compile cleanly standalone (e.g. all sources need to
include `first.h`). The manual clang-tidy implementation is fragile, and
performance, in particular when targeting Windows, is abysmal.
This patch introduces an alternate solution, enabled by the
`_CURL_TESTS_CONCAT=ON` option. In this mode, umbrella sources include
the actual sources instead of `#including` them. Allowing to use CMake's
built-in clang-tidy support to compile them, with clang-tidy actually
checking the sources. Making the manual clang-tidy support unnecessary.
In the Windows CI job it results in a 4x performance improvement (4m ->
1m), making it practical to run clang-tidy on tests on Windows, in CI.
The main downside is that clang-tidy doesn't understand the `#line`
directive. Meaning issues found show the wrong filename and line number
next to them. It's not impossible to locate errors this way, but also
not convenient.
Minor/potential downside is that the concatenated source needs to be
reassembled each time an original source is updated. This may result in
more copying on the disk when used in local development. The largest
source is 1.4MB, so probably not a show-stopper on most machines.
Another is the complexity of maintaining two methods in parallel, which
may be necessary till clang-tidy understands `#line`:
https://github.com/llvm/llvm-project/issues/62405
This solution may in theory also enable adding clang-tidy support for
tests in autotools, though I haven't tried.
Targeted for curl CI for now, and used in a GHA/windows job. 100%
experimental, not recommended outside these.
Closes#20667
Previous tag v6 changed upstream and points to a different commit. This
made zizmor unhappy. Previous commit is now tagged v6.0 in case we need
it.
Closes#20591
Upgrade a GHA/windows job to VS2026 (from VS2022), using a runner image
released a week ago. It also comes with the same Windows SDK as VS2022:
v10.0.26100.0.
The runner image uses Windows 2025 unfortunately, which makes the job
run significantly slower than before this patch:
- configure: 49s -> 1m10s
- build: 3s -> 5s
- install test prereqs: 23s -> 27s
- run tests: 3m18s -> 4m11s
- build examples: 15s -> 25s
It's a shame.
Also:
- cmake: enable picky warnings for VS2026 internal version 19.50.
Build is clean with existing options.
- GHA/windows: make the built-in OpenSSH intall path recognize
the windows-2025-vs2026 image as windows-2025.
- windows-2025-vs2026 is able to load the cached stunnel made on
the windows-2022 runner.
- disk use of the build is almost identical to VS2022.
Before: https://github.com/curl/curl/actions/runs/21955482367/job/63418133880
After: https://github.com/curl/curl/actions/runs/21957589847/job/63426546943
Ref: 71f0157880/images/windows/Windows2025-VS2026-Readme.md
Ref: #20575Closes#20577
- update `actions/checkout` from 6.0.1 to 6.0.2
- update `ruff` from 0.14.11 to 0.14.14
- update `cryptography` from 46.0.3 to 46.0.4
- update `psutil` from 7.2.1 to 7.2.2
- update `websockets` from 15.0.1 to 16.0
Closes#20490Closes#20491
It has been happening for a long time.
Example:
```
test 3001...[HTTPS localhost, last subject alt name matches, CN does not match]
3001: protocol FAILED!
There was no content at all in the file log/7/server.input.
Server glitch? Total curl failure? Returned: 56
== Contents of files in the log/7/ directory after test 3001
=== Start of file commands.log
../src/curl.exe -q --output log/7/curl3001.out --include --trace-ascii log/7/trace3001 --trace-time -4 --cacert ./certs/test-ca.crt https://localhost:64259/3001 > log/7/stdout3001 2> log/7/stderr3001
=== End of file commands.log
=== Start of file http_server.log
13:57:47.951283 Running HTTP IPv4 version on port 64256
=== End of file http_server.log
=== Start of file https_stunnel.log
2026.01.28 13:57:48 LOG5[ui]: stunnel 5.76 on x64-pc-mingw32-gnu platform
2026.01.28 13:57:48 LOG5[ui]: Compiled/running with OpenSSL 3.5.4 30 Sep 2025
[...]
2026.01.28 13:57:49 LOG5[0]: Service [curltest] accepted connection from 127.0.0.1:64281
2026.01.28 13:57:51 LOG3[0]: s_connect: connect 127.0.0.1:64256: Connection refused (WSAECONNREFUSED) (10061)
2026.01.28 13:57:51 LOG3[0]: No more addresses to connect
2026.01.28 13:57:51 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
=== End of file https_stunnel.log
=== Start of file server.cmd
Testnum 3001
=== End of file server.cmd
=== Start of file stderr3001
curl: (56) Recv failure: Connection was reset
=== End of file stderr3001
[...]
RUN: Unknown server on our https port: 64259 (56)
```
Ref: https://github.com/curl/curl/actions/runs/21440845836/job/61743268798?pr=20461Closes#20462
A cache entry created by windows-2022 is not picked up by
windows-11-arm. Also a cache created by windows-11-arm is not picked up
by windows-2022. Possibly related to this filed in 2025 June:
https://github.com/actions/cache/issues/1622. Also tried
`enableCrossOsArchive` to no avail. Unclear if these two runners count
as distinct operating systems, I'd guess not. Cache entries are
identical on the web UI. Via GH API they show up with the same cache key
bot different "version" (hash) and different sizes, possibly due to the
zstd vs. gzip bug above.
Fixing (identical error text on either runner):
```
Error: Failed to restore cache entry. Exiting as fail-on-cache-miss is set. Input key: Windows-stunnel-5.76-amd64
```
Also fix a silly typo in the shell value.
Follow-up to 0f54ca6150#20454Closes#20456
