forked from curl/curl
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[pull] master from curl:master #597
Open
pull
wants to merge
6,806
commits into
Rachelmorrell:master
Choose a base branch
from
curl:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
+277,265
−203,426
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Unified, extended, clarified the return values for numerous functions Closes #15899
Expand a little. - mention the type name of the return code - avoid stating which exact return codes that might be returned, as that varies over time, builds and conditions - avoid stating some always return OK - refer to the manpage documenting all the return codes Closes #15900
Adjusted badwords to find them. Plus: make badwords run on all markdown files in the repo and update markdowns previously unchecked Closes #15898
An old version of GCC (4.5.2 on a mipsel) moans about the constant being too big to fit in a long. Closes #15902
ngtcp2 depends on crypto backends. nghttp2 depends on ngtcp2 and nghttp3 (for nghttpx server used in pytests). Before this patch, ngtcp2, nghttp2 weren't rebuilt when their dependencies changes. This worked fine until wolfSSL bumped its soversion and caused CI to fail because ngtcp2 was not rebuilt and was still referring to the old soname that was no longer offered by the wolfSSL package. Make sure to rebuild ngtcp2/nghttp2 when any of their dependencies bump. To avoid rebuilding everything on every wolfSSL commit, switch to use wolfSSL stable versions. Bug: #15882 (comment) Closes #15885
The same goes for *SEEKDATA. Closes #15903
Test 486 verifies. Reported-by: Yihang Zhou Closes #15908
To make sure they are not spellchecked. Also, leaving two backticks is not good because they cause the spellchecker to misinterpret the markdown file so they have to be removed as well.
So that we can use words in links without having them spellchecked. Closes #15910
Via these variables, as lists: - `CURL_SUPPORTED_PROTOCOLS` - `CURL_SUPPORTED_FEATURES` As individual flags: - `CURL_SUPPORTS_<protocol/feature>` = `TRUE` Also: - set `CURL_VERSION_STRING` which was missing when using `find_package(CURL CONFIG)` or `find_package(CURL NO_MODULE)`. - set `CURL_<prototol/feature>_FOUND` for compatibility. - show full list of missing but required `COMPONENTS`. Assisted-by: Derek Huang Fixes #15854 Closes #15858
``` ./.libs/lt-upload-pausing.c: In function 'lt_fatal': ./.libs/lt-upload-pausing.c:593:1: warning: function might be candidate for attribute 'noreturn' [-Wsuggest-attribute=noreturn] 593 | lt_fatal (const char *file, int line, const char *message, ...) | ^~~~~~~~ ``` https://github.com/curl/curl/actions/runs/12611924141/job/35148104431?pr=15911#step:11:264 Ref: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wsuggest-attribute_003d Closes #15915
Bumps [cygwin/cygwin-install-action](https://github.com/cygwin/cygwin-install-action) from 4 to 5. - [Release notes](https://github.com/cygwin/cygwin-install-action/releases) - [Commits](cygwin/cygwin-install-action@006ad0b...f61179d) --- updated-dependencies: - dependency-name: cygwin/cygwin-install-action dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Closes #15918
MSVC 1900 and older is missing a `const` specifier in the `inet_ntop()` declaration for the second argument. A workaround was in place for it in cmake, but it didn't cover all necessary versions. Replace the workaround with a different one, move it to `lib/inet_ntop.c` and extend to all necessary MSVC versions. Also add CI jobs for the older MSVC versions: 2013, 2015, 2017. Closes #15923
- bump cookie counter and "creation time" to use 'unsigned int' - use BIT() for single-bit struct field - make invalid_octets() return bool properly Closes #15921
To avoid collision with a 3rd-party `RESERVED` symbols. This symbol is used in the public header of MSH3 0.7.0. Closes #15929
Starting GHA runner image 20250105.1.0. As seen on Linux with 0.7.0: ``` /home/runner/msh3/include/msh3.h:377:18: error: width of ‘RESERVED’ exceeds its type 377 | bool RESERVED : 5; | ^~~~~~~~ /home/runner/msh3/include/msh3.h:490:18: error: width of ‘RESERVED’ exceeds its type 490 | bool RESERVED : 7; | ^~~~~~~~ ``` https://github.com/curl/curl/actions/runs/12655717818/job/35266716846#step:35:195 Bug: #15924 (comment) Bug: #15930 (comment) Closes #15927
The previous runtime check using strcmp() risks failing when zlib reaches 1.10. While this instead changes the logic to a cruder build-time instead of runtime, it avoids the 1.10 risk. I verified that ZLIB_VERNUM has been provided since at least the 1.2.0.3 release. 1.2.0.4 was released on 10 August 2003. Reported-by: Fay Stegerman Closes #16202
and bump curlver to 8.12.1 while "cooling off"
... and check it early, once. Closes #16159
Make setopt fail for SSH backends not supporting knownhosts or pub md5 Closes #16204
Authored-by: Kai Pastor Ref: microsoft/vcpkg@0ed3bfe Closes #16190
Instead of relying on the default `-A x64` on `windows-latest` runners, tell cmake the arch explicitly, to be in sync with `matrix.arch`. Also add support for arm64 and x86. `-DVCPKG_TARGET_TRIPLET=` isn't enough to select the platform, ref: https://github.com/curl/curl/actions/runs/13179082565/job/36785363766?pr=16210 Closes #16210
Sync the test path with test1515. If fixes the test when the perl tool resides on a path with spaces in it. E.g. when using the perl from Git for Windows. This is a workaround, there may be a better fix this type of issue. Similar fix for test1515: 38b0554 Failure: ``` test 1516...[caching of manual libcurl DNS entries after dead connection] lib1515.exe returned 3, when expecting 0 1516: exit FAILED === Start of file stderr1516 Test: lib1515 [...] 17:59:32.390000 == Info: Expire cleared request http://testserver.example.com:63621/C:/Program Files/Git/path/15160001 failed with 3 Test ended with result 3 === End of file stderr1516 ``` Ref: https://github.com/curl/curl/actions/runs/13184790755/job/36804217128?pr=16217#step:13:2805 Closes #16223
In certain Windows configurations, Perl resides under `C:/Program Files` causing tests to fail when executing Perl. Fix by quoting the command. Seen in `dl-mingw` jobs when switching to the default `bash` shell offered by the `windows-latest` runner on GHA. Also: - apply the same fix for `valgrind` for consistency. - make more use of `shell_quote()` when passing the `srcdir` directory over the command-line. This doesn't come up in CI, but seems like good practice. There are lots more unquoted arguments and possibly also commands. ``` -------e--- OK (940 out of 1537, remaining: 00:32, took 0.217s, duration: 00:50) test 1167...[Verify curl prefix of public symbols in header files] /C/Program Files/Git/usr/bin/perl -I. -ID:/a/curl/curl/tests returned 127, when expecting 0 1167: exit FAILED [...] === Start of file stderr1167 sh: line 1: /C/Program: No such file or directory ``` Ref: https://github.com/curl/curl/actions/runs/13181757313/job/36794072190?pr=16217#step:13:2107 Closes #16220
The null byte was not necessary for the test
libssh 0.9.0 was shipped on June 28 2019 and is the first version featuring the knownhosts API Drop libssh from the GHA/linux-old CI job since it gets a libssh 0.7.3 version, too old for us now. Closes #16200
useless on ubuntu-24.04 (ubuntu-latest) as it uses read-only fs Closes #16224
Requires CMake 3.20: https://cmake.org/cmake/help/latest/command/cmake_path.html Co-authored-by: Kai Pastor Ref: microsoft/vcpkg@307e1f9 Closes #16191
It should be done if "threaded-resolver" is enabled, but the detection was slightly broken for builds that add c-ares for the asyn-rr feature. Closes #16226
- `set(VAR "${VAR}<value>")` -> `string(APPEND VAR "<value>")` Available since CMake 3.4: https://cmake.org/cmake/help/latest/command/string.html#append - `set(VAR "${VAR2}-or-<value>;${VAR}")` -> `set(VAR "${VAR2}-or-<value>" ${VAR})` Closes #16144
As detected using `cmake --warn-uninitialized`. It also lists: - variables inherited from `Makefile.inc`, which this PR does not fix. - a documented CMake global variable, which is unexpected: `CMAKE_MODULE_PATH`. I'd expect CMake to initialize its namespace. - envs: `CI`, `CURL_CI` and `CURL_BUILDINFO`. Unexpected, as the manual mentions variables only. As of August 2024, there is no solution to silence them: https://discourse.cmake.org/t/how-to-test-for-set-env-variables-without-getting-warnings/11401 https://cmake.org/cmake/help/latest/manual/cmake.1.html#cmdoption-cmake-warn-uninitialized Closes #16198
This issue was not addressed with CMake builds so far. curl-for-win worked thanks to its `-Wl,--start-group` workaround. It affects binutils `ld` linking statically. Shared linking and llvm's `lld` doesn't need strict lib order, and are not affected. The solution is to pass libs in dependency order, with least dependent (e.g. system) libs last. In case of cyclic dependency, may pass libs twice. Fix most issues by moving Windows system libs `ws2_32` and `bcrypt` last, and move SSH libs first due to their dependence on crypto backends and zlib compression. Also: - modify an existing Linux curl-for-win job to use gcc. - add a specific Windows gcc job to test this. Make it use different options than the default to extend build coverage too: `libssh`, `zlib-ng`, 32-bit. - prefer CMake imported targets for OpenSSL and ZLIB. Examples of issues fixed: Windows LibreSSL, libpsl vs. ws2_32: ``` x86_64-w64-mingw32-ld: curl/libressl/lib/libcrypto.a(bss_sock.c.obj):bss_sock.c:(.text$sock_ctrl[sock_ctrl]+0x59): undefined reference to `__imp_shutdown' x86_64-w64-mingw32-ld: curl/libressl/lib/libcrypto.a(gcm128.c.obj):gcm128.c:(.text$CRYPTO_gcm128_init[CRYPTO_gcm128_init]+0x65): undefined reference to `__imp_ntohl' x86_64-w64-mingw32-ld: curl/libpsl/_x64-win-ucrt/usr/lib/libpsl.a(psl.o):(.text$psl_is_cookie_domain_acceptable+0xef): undefined reference to `__imp_WSAStringToAddressW' ``` Ref: https://github.com/curl/curl/actions/runs/13157579253/job/36718144881?pr=16182#step:3:5354 Linux libssh2 vs. zlib: ``` /usr/lib/gcc-cross/aarch64-linux-gnu/12/../../../../aarch64-linux-gnu/bin/ld: curl/libssh2/_a64-linux-gnu-libressl/usr/lib/libssh2.a(unity_0_c.c.o): in function `comp_method_zlib_dtor': (.text.comp_method_zlib_dtor+0x8c): undefined reference to `deflateEnd' /usr/lib/gcc-cross/aarch64-linux-gnu/12/../../../../aarch64-linux-gnu/bin/ld: curl/libssh2/_a64-linux-gnu-libressl/usr/lib/libssh2.a(unity_0_c.c.o): in function `comp_method_zlib_comp': (.text.comp_method_zlib_comp+0x50): undefined reference to `deflate' /usr/lib/gcc-cross/aarch64-linux-gnu/12/../../../../aarch64-linux-gnu/bin/ld: curl/libssh2/_a64-linux-gnu-libressl/usr/lib/libssh2.a(unity_0_c.c.o): in function `comp_method_zlib_init': (.text.comp_method_zlib_init+0x8c): undefined reference to `deflateInit_' ``` Ref: https://github.com/curl/curl/actions/runs/13157270420/job/36717189086?pr=16182#step:3:5285 Windows libssh vs. ws2_32 and LibreSSL: ``` /usr/bin/i686-w64-mingw32-ld: curl/libssh/_x86-win-ucrt-libressl/usr/lib/libssh.a(connect.c.obj):(.text$ssh_connect_host_nonblocking+0x92): undefined reference to `WspiapiGetAddrInfo@16' /usr/bin/i686-w64-mingw32-ld: curl/libssh/_x86-win-ucrt-libressl/usr/lib/libssh.a(connect.c.obj):(.text$ssh_connect_host_nonblocking+0x3d9): undefined reference to `gai_strerrorA' /usr/bin/i686-w64-mingw32-ld: curl/libssh/_x86-win-ucrt-libressl/usr/lib/libssh.a(kex.c.obj):(.text$ssh_client_select_hostkeys+0xd2): undefined reference to `FIPS_mode' /usr/bin/i686-w64-mingw32-ld: curl/libssh/_x86-win-ucrt-libressl/usr/lib/libssh.a(options.c.obj):(.text$ssh_options_set+0x942): undefined reference to `FIPS_mode' ``` Ref: https://github.com/curl/curl/actions/runs/13163986294/job/36739557888?pr=16182#step:3:5127 Ref: https://github.com/curl/curl/actions/runs/13163986294/job/36739557888?pr=16182#step:3:5121 Closes #16182
The latest copy I could find at: https://beta.novell.com/developer/ndk/ldap_libraries_for_c.html is from 2016-Feb-03, available for Linux and Windows. I built curl against the Windows package with CMake: https://sdk.suse.com/ndk/cldap/builds/2016/openldapsdk-devel-windows64-2016-01-28.zip (It comes with OpenSSL 1.0.1q-fips (2015-Dec-03) binaries.) CMake identified it as OpenLDAP and built with it as expected: ``` curl 8.12.0-DEV (x86_64-w64-mingw32) libcurl/8.12.0-DEV Schannel OpenLDAP/2.4.37 Release-Date: [unreleased] Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss Features: alt-svc AsynchDNS HSTS HTTPS-proxy IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI threadsafe UnixSockets ``` Since it identified it as OpenLDAP (`lib/openldap.c`), the branch deleted in this PR (`lib/ldap.c`) wasn't reached. Thus, defining the `CURL_HAS_NOVELL_LDAPSDK` also made no difference in the build. This suggests the code guarded by it is now orphan and unnecessary. Novell NetWare builds were another user, but we dropped support for them in 2022: 3b16575 #8358 Closes #16176
Some places where still referencing them via global variables. Closes #16207
… `pkg-config` For Find modules where `<Modulename>` is not fully uppercase. `<Modulename>` is case-exact name used in the Find modules filename: `CMake/Find<Moduleame>.cmake`. `find_package_handle_standard_args()` sets both `<MODULENAME>_FOUND` and `<Modulename>_FOUND` when detecting the dependency. Some CMake code relies on this and 3rd-party code may rely on it too. Make sure to set the latter variant when detecting the dependency via `pkg-config`, where we don't call `find_package_handle_standard_args()`. CMake sets these variable to `TRUE` (not `ON` or `1`). Replicate this for compatibility. Closes #16153
Add CMake test project consuming curl via these methods: `FetchContent`, `add_subdirectory()`, `find_package()`. Also: - GHA/distcheck: run these tests in CI. - cmakelint: exclude a warning for calling "wonky-cased" built-in CMake functions, such as `FetchContent_Declare()`. Closes #16126
Today GHA Windows runner images (all versions) deployed an upgrade (20250127.1.0 -> 20250203.1.0) that upgraded the default MSYS2, which now seems to feature the October 2024 issue that caused curl runtests run times increasing ~2.5x. It also causes test987 to fail, and vcpkg jobs hitting their time limits and fail. Reliability also got a hit. In October this issue came with a Git for Windows upgrade, and likely the MSYS2 runtime update within it. It affected vcpkg jobs only, and I mitigated it by switching them to use the default MSYS2 shell and runtime (at `C:\msys64`): 5f9411f #15380 After today's update this mitigation no longer works. The issue also affects `dl-mingw` jobs now, though to a lesser extent than vcpkg ones. Tried switching back to Git for Windows which received several updates since October, but the performance issue is still present. I managed to mitigate the slowdown in vcpkg by lowering test parallelism to `-j4` (from `-j8`), after which the jobs are about *half the speed* than before, and fit their time limits. `dl-mingw` builds run slower by 1-1.5 minutes per job, they were already using `-j4`. Example jobs: Before (ALL GOOD): https://github.com/curl/curl/actions/runs/13167230443/job/36750175428 installed MSYS2, mingw (-j8): 3m50s (OK) https://github.com/curl/curl/actions/runs/13167230443/job/36750158662 default MSYS2, dl-mingw (-j4): 4m22s (OK) https://github.com/curl/curl/actions/runs/13167230443/job/36750163392 default MSYS2, vcpkg (-j8): 3m27s (OK) runner: https://github.com/actions/runner-images/blob/win22/20250127.1/images/windows/Windows2022-Readme.md C:\msys64: System: MSYS_NT-10.0-20348 fv-az1115-916 3.5.4-0bc1222b.x86_64 2024-12-05 09:27 UTC x86_64 Msys msys2/msys2-runtime@0bc1222b After: https://github.com/curl/curl/actions/runs/13186498273/job/36809747078 installed MSYS2, mingw (-j8): 3m48s (OK) https://github.com/curl/curl/actions/runs/13186498273/job/36809728481 default MSYS2, dl-mingw (-j4): 5m56s (SLOW) https://github.com/curl/curl/actions/runs/13186498273/job/36809736429 default MSYS2, vcpkg (-j8): 9m1s (SLOW) runner: https://github.com/actions/runner-images/blob/win22/20250203.1/images/windows/Windows2022-Readme.md C:\msys64: System: MSYS_NT-10.0-20348 fv-az1115-498 3.5.7-2644508f.x86_64 2025-01-30 09:08 UTC x86_64 Msys msys2/msys2-runtime@2644508f windows-2025 image: C:\msys64: System: MSYS_NT-10.0-26100 fv-az2043-515 3.5.7-2644508f.x86_64 2025-01-30 09:08 UTC x86_64 Msys windows-2019 image: C:\msys64: System: MSYS_NT-10.0-17763 fv-az1434-677 3.5.7-2644508f.x86_64 2025-01-30 09:08 UTC x86_64 Msys This PR: final: https://github.com/curl/curl/actions/runs/13186498273/job/36809736429 GfW, vcpkg (*-j4*): ~7m (SLOW) test: https://github.com/curl/curl/actions/runs/13187992987/job/36814644852?pr=16217, GfW, vcpkg (-j8): ~11m (SLOWER) Before and after (unused) Git for Windows (SLOW as tested in this PR): C:\Program Files\Git System: MINGW64_NT-10.0-20348 fv-az1760-186 3.5.4-395fda67.x86_64 2024-11-25 09:49 UTC x86_64 Msys msys2/msys2-runtime@395fda67 (fork) Before and after (used) MSYS2 installed via msys2/setup-msys2 (OK): D:\a\_temp\msys64 System: MINGW64_NT-10.0-20348 fv-az836-378 3.5.4-0bc1222b.x86_64 2024-12-05 09:27 UTC x86_64 Msys Perl pipe issue report from October, still open: msys2/msys2-runtime#230 ARM deadlock fixed by GfW 2.47.1(1), but for x86_64, on a quick glance: msys2/msys2-runtime@290bea9 Possibly interesting: msys2/msys2-autobuild#62 Closes #16217
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )