FD_SETSIZE is irrelevant when using poll. So ensuring that the file
descriptor is smaller than FD_SETSIZE in VALID_SOCK, can cause
multi_wait to ignore perfectly valid file descriptors and simply wait
for 1s to avoid hammering the CPU in a busy loop.
Fixes#7240Closes#7241
"get-easy-options" is the configure option advertised by the help text
anyway, so use that.
Fixes#7211Closes#7213
Follow-up to ad691b191 ("configure: added --disable-get-easy-options")
Suggested-by: Daniel Stenberg <daniel@haxx.se>
Signed-off-by: Bastian Krause <bst@pengutronix.de>
To make it easier to write ranges like '115 to 229' without that
explicitly enabling tests that are listed in DISABLED, this makes
runtests always skip disabled tests unless the -f command line option is
used.
Previously the code attempted to not run such tests, but didn't do it
correctly.
Closes#7212
The latest GnuTLS-3.7.2 implements disable switch for TLSv1.3 compatible
mode for middle box but it is enabled by default, which is unnecessary
for QUIC.
Fixes#6896Closes#7202
Removing expired cookies needs to be a fast operation since we want to
be able to perform it often and speculatively. By tracking the timestamp
of the next known expiration we can exit early in case the timestamp is
in the future.
Closes: #7172
Reviewed-by: Daniel Stenberg <daniel@haxx.se>
Warning: this will make existing curl command lines that use metalink to
stop working.
Reasons for removal:
1. We've found several security problems and issues involving the
metalink support in curl. The issues are not detailed here. When
working on those, it become apparent to the team that several of the
problems are due to the system design, metalink library API and what
the metalink RFC says. They are very hard to fix on the curl side
only.
2. The metalink usage with curl was only very briefly documented and was
not following the "normal" curl usage pattern in several ways, making
it surprising and non-intuitive which could lead to further security
issues.
3. The metalink library was last updated 6 years ago and wasn't so
active the years before that either. An unmaintained library means
there's a security problem waiting to happen. This is probably reason
enough.
4. Metalink requires an XML parsing library, which is complex code (even
the smaller alternatives) and to this day often gets security
updates.
5. Metalink is not a widely used curl feature. In the 2020 curl user
survey, only 1.4% of the responders said that they'd are using it. In
2021 that number was 1.2%. Searching the web also show very few
traces of it being used, even with other tools.
6. The torrent format and associated technology clearly won for
downloading large files from multiple sources in parallel.
Cloes #7176
The `find_libarary` command resolves the library or framework
into an absolute path. In case of system frameworks which are
located within an Xcode-provided SDK this results in the Xcode
path and SDK version being part of the library path.
Because those library paths end up in the exported CMake config
importing curl will fail once the Xcode location or SDK version
changes:
```cmake
set_target_properties(CURL::libcurl PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
INTERFACE_LINK_LIBRARIES "lber;ldap;/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/SystemConfiguration.framework;OpenSSL::SSL;OpenSSL::Crypto;ZLIB::ZLIB"
)
```
A work-around is to link against system-level frameworks with
`-framework XYZ`. In case of `SystemConfiguration` we might be able
to omit the lookup-check because we could assume the framework is
always present.
Closes#7152
Trying dual-stack on some embedded platform, I noticed that quite
frequently (20%) libCurl starts from IPv4 regardless the Happy Eyeballs
timeout value. After debugging this issue, I noticed that this happens
if c-ares resolver response for IPv6 family comes before IPv4 (which was
randomly happening in my tests).
In such cases, because libCurl puts the last resolver response on top of
the address list, when IPv4 resolver response comes after IPv6 one - the
IPv4 family starts the connection phase instead of IPv6 family.
The solution for this issue is to always put IPv6 addresses on top of
the address list, regardless the order of resolver responses.
Bug: https://curl.se/mail/lib-2021-06/0003.htmlCloses#7188
