- It is slower and uses more memory than the alternatives and is only
experimental in curl.
- We disable a few tests for OpenSSL-QUIC because of flakiness
- It gets little attention from OpenSSL and we have no expectation of the
major flaws getting corrected anytime soon.
- No one has spoken up for keeping it
- curl users building with vanilla OpenSSL can still use QUIC through the
means of ngtcp2
Closes#20226
With the same semantics as Apple SecTrust, in both libcurl and the curl
tool, when using non-Schannel TLS backends. In practice it means that
it makes TLS work without manually or implicitly configuring a CA bundle
`.crt` file, such as `curl-ca-bundle.crt`.
To enable:
- autotools: `--enable-ca-native`
- cmake: `-DCURL_CA_NATIVE=ON`
- CPPFLAGS: `-DCURL_CA_NATIVE`
When enabled:
- enables `CURLSSLOPT_NATIVE_CA` (libcurl) / `--ca-native`
and `--proxy-ca-native` (curl tool) options by default.
- unsafe search for an on-disk CA bundle gets disabled by default.
Equivalent to `--disable-ca-search` with autotools,
`-DCURL_DISABLE_CA_SEARCH=ON` with CMake.
- build-time detection of CA bundle and CA path gets disabled. As with
Apple SecTrust. This was already the default for Windows.
- native CA can be disabled at run-time with the `--no-ca-native`
and/or `--no-proxy-ca-native` command-line options.
Rationale: This build option:
- has a repeat and active interest from packagers and users.
- helps integrating curl with Windows for those who need this.
- it also applies to macOS: #17525
Shipped in curl 8.17.0.
- makes it trivial to use custom certs configured on the OS.
- frees applications/packagers/users from the task of securely
distributing, and keeping up-to-date, a CA bundle.
- frees potentially many curl tool from configuring a CA bundle manually
to access HTTPS (and other TLS) URLs. This is traditionally difficult
on Windows because there is no concept of a universal, protected,
non-world-writable, location on the file system to securely store
a CA bundle.
- allows using modern features regardless of Windows version. Some of
these features are not supported with Schannel (e.g. HTTP/3, ECH) on
any Windows version.
- is necessary for HTTP/3 builds, where bootstrapping a CA bundle is not
possible with Schannel, because MultiSSL is not an option, and HTTP/3
is not supported with Schannel.
Ref: #16181 (previous attempt)
Ref: https://github.com/curl/curl/discussions/9348
Ref: https://github.com/curl/curl/issues/9350
Ref: https://github.com/curl/curl/pull/13111
Ref: https://github.com/microsoft/vcpkg/pull/46459#issuecomment-3162068701
Ref: 22652a5a4c#14582
Ref: eefd03c572#18703Closes#18279
After this patch curl requires targeting Vista or newer, and a toolchain
with Vista support.
Supported MSVC compilers (VS2010+) all support Vista:
- VS2012+ target Win8 (or later) by default.
- VS2010 targets Win7 by default.
Supported mingw-w64 versions (v3+) all support Vista:
- mingw-w64 v9+ target Win10 by default.
- mingw-w64 v8 and older target Server 2003 (~XP) by default.
After this patch it may be necessary to override the default Windows
target version to Vista (or newer) via:
autotools: `CPPFLAGS=-D_WIN32_WINNT=0x0600`
cmake: `-DCURL_TARGET_WINDOWS_VERSION=0x0600`
- mingw-w64 v6+ allow changing the default at toolchain build-time.
Notes:
- For non-MSVC, non-mingw-w64 toolchains, `if_nametoindex` needs to be
allowlisted in `curl_setup.h`, if they do support it.
Fixes#17985 (discussion)
Closes#18009
- MSYS2/Cygwin bash shells are now tagged "misfeature".
It is not something we can fix. We need these shells, and using
documented/necessary settings to use these environments should be
allowed without workarounds.
- untagged actions within curl's own organization are now also flagged
as "action is not pinned to a hash (required by blanket policy)". This
seems overkill. Making internal releases would not be helpful or
practical. Also considering that the referred internal action uses an
unpinned external action anyway (google/oss-fuzz/infra/cifuzz), with
near-zero chance to fix.
Ref: https://github.com/zizmorcore/zizmor/pull/1517#issuecomment-3759740853Closes#20339
- update `ruff` from 0.14.10 to 0.14.11
- update `filelock` from 3.20.1 to 3.20.3 (CVE-2026-22701) (used in pytests)
- update `psutil` from 7.2.0 to 7.2.1
Closes#20300
To simplify the directory layout.
- OS400 and vms support move from `packages` to `projects`.
- Windows README and `generate.bat` files move from `projects`
to `projects/Windows`.
Closes#20271
To run checksrc and spacecheck on the source tree. Also for cmake
to sync up with autotools' `checksrc` target.
- cmake: `curl-lint`
With `-DCURL_LINT=ON`, checks run automatically for all targets.
- autotools: `lint`
Closes#20175
Turns out in practice the internal cache name contains the arch where it
matters (arm or dual-arch local builds), which is part of the cache key
string. Drop `runner.arch` to avoid two arch strings in the key.
Cache keys without an explicit arch designator mean intel.
Revert ff78af5752#20234Closes#20249
`mbedtls-arm` and `mbedtls-prev` were matching `contains()` expressions
looking for `mbedtls`. It caused an unnecessary cache restore and an
redundant mbedtls build on bumps, and made the build flavors require
different local directory names to avoid this accidental collision.
Also drop `-threadsafe` from internal names. All local builds are.
Follow-up to 8806035344#20240
Follow-up to 3a305831d1#19077Closes#20248
All libresll jobs, wolfssl-all, and one mbedtls job.
As noted earlier, arm jobs run faster than intel ones, especially
valgrind steps that run almost twice as fast. Package install runs
slower, but this is offset by faster build and test steps, even in
non-valgrind jobs.
Follow-up to ff78af5752#20234
Follow-up to 2b0d8dcc16#20231Closes#20246
`libressl-filc` was matching `contains()` expressions looking for
`libressl`, causing build confusion and failure in specific cases.
Rename `libressl` to `libressl-c` to avoid this. Also rename the cache
id for consistency, though not necessary for the fix.
Bug: https://github.com/curl/curl/actions/runs/20860412340/job/59938315276
Follow-up to c262481873#19407
Cherry-picked from #20234Closes#20240
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.
Closes#20231
To:
- see if build tool makes a difference for flaky 8x pytest slowdowns.
- to make this job finished faster.
`curl -V`, number of runtests (1793) and pytests (568/159) verified
to remain the same.
Closes#20211
For `PRI*` printf masks for fixed-size C99 types.
Also:
- add simple fallback for `PRIu32`, `PRIx32`, if `inttypes.h` is
missing.
Cherry-picked from #20200
Ref: #20207
Follow-up to 4701a6d2ae#19695
Ref: 60359ad504#12275Closes#20208
Number of jobs down to 34 (from 56 at end of last year.)
Out of them 7 autotools (was 24 at end of last year.)
Also:
- stop install brew packages preinstalled.
- make some dependency options explicit.
Closes#20203
To save 0.5 to 3 minutes per job.
There remain 7 main autotools jobs, plus 1 in combinations and 1 more
for iOS.
Also:
- fix to disable MQTT, WebSockets, IPFS in HTTP-only job.
Closes#20193
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.
Follow-up to b869932392#20178Closes#20187
- 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).
Before: https://github.com/curl/curl/actions/runs/20637652089
After: https://github.com/curl/curl/actions/runs/20686390641?pr=20178
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).
Follow-up to d057b705fd#20167Closes#20178
It also means that now all torture test-pairs use the same shallowness,
while earlier FTP used 20.
Also:
- This made macOS torture jobs slow enough to split them into 3 jobs.
Follow-up to 2cbcde90e7#20153Closes#20172
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.
Closes#20170
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.
Follow-up to ff958fc4b2#20159Closes#20167
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.
Related perf improvements from today:
- make scan-build 2x fast:
ff958fc4b2#20159
- drop build-only Testi386 fuzz workflow (from curl), saving 9m per run:
0106023c1fhttps://github.com/curl/curl-fuzzer/pull/236Closes#20153
To make the longest running FreeBSD job finish 1.5 minutes faster
(9.5m -> 8m).
Examples are still built with both autotools and cmake, one on Intel and
one on ARM.
Closes#20146
- 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
Closes#20140
