Skip to content
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
wants to merge 6,806 commits into
base: master
Choose a base branch
from
Open

[pull] master from curl:master #597

wants to merge 6,806 commits into from

Conversation

pull[bot]
Copy link

@pull pull bot commented Jul 11, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

vszakats and others added 27 commits January 2, 2025 14:44
No longer used by curl tests.

`--output-dir` option can be used as an alternative in all builds.

Follow-up to 39697de #15114
Closes #15893
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
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
This isn't needed anymore after #15835,
since banned functions are just allowed in general in
`docs/examples/.checksrc`, and emits a warning when running make
checksrc:

`invalid warning specified in .checksrc: "SNPRINTF"`

Closes #15916
Subparts may have been previously used as a top-level mime structure and
thus not rewound.

New test 695 checks the proper functioning in these particular conditions.

Reported-by: Qriist on github
Fixes #15842
Closes #15911
Count connections to a host against a possibly configured destination
limit. Trigger multi `connchange` when a connection has been shutdown,
so pending transfers can try to get a connection once again.

Reported-by: baranyaib90 on github
Fixes #15857
Closes #15879
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
bagder and others added 30 commits February 6, 2025 10:26
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"
Made the netrc parser return a more consistent set of error codes and
error messages, and also return error properly if the .netrc file is
missing.

Add test 697 to verify error on missing netrc file.

Fixes #16163
Reported-by: arlt on github
Closes #16165
Fixes #16160
Reported-by: deliciouslytyped on github
Closes #16164
Make setopt fail for SSH backends not supporting knownhosts or pub md5

Closes #16204
As `tool_hugehelp.c` is no longer included into `Makefile.inc`,
I did add it explicitly to list of source files built on IBMi.

Follow-up to 96843f4 #16068
Fixes #16214
Closes #16215
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
It was wrongly bumped to 1.16.0 in db50fc6. While we strongly
recommend using 1.16.0 or later, we still allow builds using older
versions.

It would make sense to raise the requirement to at least 1.11.0 (Feb 19
2016) but that's not done right now.

Closes #16221
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
Instead of picky-backing on the libcurl one using the curlx shortcut,
which is fragile since the libcurl one is not present in all builds.

Reported-by: mschroeder-fzj on github
Fixes #16201
Closes #16203
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
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
We set this macro to silence a warning inside `openldap.h`. With this
warning now silenced by using `-isystem`, we can drop it. Also it never
had to be set to `1`.

Also enable OpenLDAP in a CMake GHA/macos job.

Follow-up to 445fb81 #14763
Follow-up to 751e168 #12024

Closes #16146
… `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
Projects
None yet
Development

Successfully merging this pull request may close these issues.