Windows sometimes has issues when opening the same file twice, so these
test two situations where that could potentially occur.
Reported-by: ralfjunker on github
Ref: #15043Closes#15045
Test expected a connect to a port no one is listening to immediately
fail. But Windows has its internal retry logic that may fail this.
As fix, multi_perform()/multi_wait() until transfer is done.
Closes#15054
SANITIZE_ALLOW_TRUNCATE and SANITIZE_ALLOW_COLONS were never used by
code, thus only making the code complicated for no good use.
Since nothing should truncate, using strncpy() is wrong.
Two cases of malloc + copy replaced with proper strdup() calls.
Fixup unit test 1604 accordingly.
Closes#15047
This is the %CLIENT6IP variable - but without outmost brackets since
some commmand lines need the address without the brackets. With this
variable we can run three more tests without prechecks.
Closes#15039
Also introduce 'notexists' for verifying that directory entries do not
exist after a test. Now an explicit supported feature instead of using
"funny" perl in postcheck.
Closes#15046
Since it seems the _POSIX_C_SOURCE "trick" does not work there, the
check does not find poll().
Fixes#15013
Reported-by: vvb2060 on github
Closes#15037
It enables running pytests in cmake jobs, regardless of underlying build
tool choice (= makes it work with ninja.)
Also:
- drop pytest logic launching `make` and exiting in case of failure.
Maybe there is a better way and keep this functionality somehow, bind
it to a command-line option? make it fail softly?
- GHA/linux: invoke pytest via the build, not directly.
- autotools: add missing dummy runtests targets when cross-compiling.
Closes#15034
Valgrind jobs are slow, drop it from jobs where its use is redundant
and/or has limited impact:
- BearSSL: deprecated.
- LibreSSL heimdal with autotools.
Keep valgrind for the same job with cmake.
- msh3.
- IntelC no-SSL.
Keep valgrind for IntelC OpenSSL.
- OpenSSL 3.
All OpenSSL jobs are v3 now, keep valgrind for the `-O3`, and
libssh2 + sync-resolver variants.
Closes#15020
Add empty definition of Curl_trc_ws() to fix this following build error:
In file included from sendf.h:29,
from ws.c:35:
ws.c: In function 'Curl_ws_accept':
curl_trc.h💯10: error: implicit declaration of function 'Curl_trc_ws'; did you mean 'Curl_trc_ftp'? [-Wimplicit-function-declaration]
100 | Curl_trc_ws(data, __VA_ARGS__); } while(0)
| ^~~~~~~~~~~
ws.c:779:5: note: in expansion of macro 'CURL_TRC_WS'
779 | CURL_TRC_WS(data, "WS, using chunk size %zu", chunk_size);
| ^~~~~~~~~~~
Closes#15026
Warn/assert about a possibly stalling transfer only when it
has no timeout set.
The assertion triggered in test 1540 on loaded CI sometimes.
Closes#15028
- lib557: suppress `-Wformat-overflow` warning in source.
Fixes:
```
lib557.c: In function ‘test_float_formatting’:
lib557.c:1408:37: error: ‘%*f’ directive output of 2147483648 bytes exceeds ‘INT_MAX’ [-Werror=format-overflow=]
1408 | curl_msnprintf(buf, sizeof(buf), "%*f", INT_MIN, 9.1);
| ^~~
lib557.c:1408:3: note: ‘curl_msnprintf’ output 2147483649 bytes
1408 | curl_msnprintf(buf, sizeof(buf), "%*f", INT_MIN, 9.1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Ref: https://app.circleci.com/pipelines/github/curl/curl/10226/workflows/87642ee9-cda6-4916-8206-c82aac5f595e/jobs/107669?invite=true#step-106-40996_46
The root cause of why this option gets enabled remains undiscovered.
Reported-by: Daniel Stenberg
Fixes#15008
Follow-up to 71cf0d1fca#14772
- build: drop `-Wno-format-overflow` from picky warning list.
These options only get used with picky warnings enabled.
Follow-up to 145f87b9e8#14598
- unit1652: suppress in source (and not rely on picky warnings anymore.)
Closes#15012
Make `test-ci` not depend on the `testdeps` target.
`test-ci` is designed to run curl tests in CI. In CI we build all
necessary dependencies explicitly beforehand, and they are always ready
when calling the `test-ci` step. Thus, it isn't necessary to enforce
them via a dependency rule. Dropping it saves redundant work and delay
in CI jobs.
The `testdeps` dependency should not normally be a problem. It's
supposed to be a no-op if those targets are already built. In practice
however, it causes a delay and/or an actual rebuild of those
dependencies depending on generator (= build tool) used and other
factors.
As observed in the GHA/windows workflow, the `testdeps` dependency:
- with Ninja, causes no delay, and no extra work:
https://github.com/curl/curl/actions/runs/10980099984/job/30485440389#step:25:18
- with GNU Make, caused a re-evaluation of `testdeps` targets,
but did not actually rebuild them. This re-evaluation took a
noticeable time (esp. with non-bundled tests):
https://github.com/curl/curl/actions/runs/10980099984/job/30485440155#step:14:11 (with bundles)
https://github.com/curl/curl/actions/runs/10973851013/job/30471690331#step:14:11 (w/o bundles)
verbose: https://github.com/curl/curl/actions/runs/10980506956/job/30486434629#step:14:13
- with MSBuild, caused a re-evaluation of `testdeps` targets, and
triggered a _rebuild_:
https://github.com/curl/curl/actions/runs/10980099984/job/30485435968#step:14:19 (with bundles)
https://github.com/curl/curl/actions/runs/10973851013/job/30471689714#step:14:19 (w/o bundles)
verbose: https://github.com/curl/curl/actions/runs/10980506956/job/30486436368#step:14:48
It's suspected that our use of
`-DCMAKE_VS_GLOBALS=TrackFileAccess=false` in CI is contributing to
this. This option is supposed to affect incremental builds only. For
some reason it affects CI builds too, even though they are not
incremental, and no sources are changed between build steps.
Reported-by: Aki Sakurai
Ref: #14999
Notice that `test-*` targets depending on `testdeps` is NOT sufficient
to build everything to run tests, e.g. it misses to build the curl tool,
which is essential. This is also true for autotools' `test-ci` target
which misses to build libcurl and the curl tool.
Perhaps it'd be best to drop `testdeps` as a dependency for _all_
`test-*` targets and make it official to require building dependencies
manually. Alternatively these targets could be fixed to rebuild
everything necessary to run tests.
Closes#15001
Disable dependency tracking and enable unity + test bundles for
the `configure-libssh` job that was missed in earlier commits.
Follow-up to 71cf0d1fca#14772
Follow-up to dff66196d0#14975Closes#15010
Add `CURL_CA_SEARCH_SAFE` build-time option to enable CA bundle search
in the `curl` tool directory. The lookup method was already used to find
`.curlrc` and `_curlrc` (on Windows). On Windows it overrides the unsafe
default `SearchPath()` method.
Enable with:
- cmake: `-DCURL_CA_SEARCH_SAFE=ON`
- autotools: `--enable-ca-search-safe`
- raw: `CPPFLAGS=-DCURL_CA_SEARCH_SAFE`
On Windows, before this patch the whole `PATH` was searched for
a CA bundle. `PATH` may contain unwanted or world-writable locations,
including the current directory. Searching them all is convenient to
pick up any CA bundle, but not secure.
The Muldersoft curl distro implements such CA search via a custom
patch for Windows:
cd652d4792/patch/curl_tool_doswin.diff (L50)
MSYS2/mingw-w64 distro has also been rolling a patch solving this:
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-curl/0001-Make-cURL-relocatable.patchhttps://github.com/msys2/MINGW-packages/blob/master/mingw-w64-curl/pathtools.c
Also add option to fully disable Windows CA search:
- cmake: `-DCURL_DISABLE_CA_SEARCH=ON`
- autotools: `--disable-ca-search`
- raw: `CPPFLAGS=-DCURL_DISABLE_CA_SEARCH`.
Both options are considered EXPERIMENTAL, with possible incompatible
changes or even (partial) removal in the future, depending on feedback.
An alternative, secure option is to embed the CA bundle into the binary.
Safe search can be extended to other platforms if necessary or useful,
by using `_NSGetExecutablePath()` (macOS),
`/proc/self/exe` (Linux/Cygwin), or `argv[0]`.
Closes#14582
- linux: bump up test parallelism for valgrind tests to `-j4`
(from `-j2`). (EXPERIMENTAL)
- linux: drop `apt-get update` for the default architecture on the GHA
native runner. It makes prereq install steps complete faster.
The runner image gets weekly updates, and that should be enough to
guarantee fresh packages in most cases:
https://github.com/actions/runner-images/commits/main/images/ubuntu/Ubuntu2204-Readme.md
- aws-lc: use ninja with cmake.
- aws-lc: build examples with cmake.
- aws-lc: drop `apt update`.
- aws-lc, wolfssl, linux32, http3-linux: move building examples to
the last step.
Follow-up to 45202cbba4#14906
- windows: formatting.
Closes#14992
They are still slow in these jobs/combinations.
- non-native/FreeBSD/arm64 autotools +36s
- non-native/FreeBSD/arm64 cmake +1m
- windows/linux-cross-mingw-w64 autotools +33s
These ones remain:
- linux/aws-lc cmake +6s
- windows/linux-cross-mingw-w64 cmake +12s
Follow-up to 71cf0d1fca#14772
