1. Because the value is not strictly set with a setopt option.
2. Because otherwise when duping a handle when all the set.* fields are
first copied and an error happens (think out of memory mid-function),
the function would easily free the list *before* it was deep-copied,
which could lead to a double-free.
Closes#12323
autotools passes `LDFLAGS` automatically linker commands. curl's
`lib/Makefile.am` customizes libcurl linker flags. In that
customization, it added `LDFLAGS` to the custom flags. This resulted in
passing `LDFLAGS` _twice_ to the `libtool` command.
Most of the time this is benign, but some `LDFLAGS` options can break
the build when passed twice. One such example is passing `.o` files,
e.g. `crt*.o` files necessary when customizing the C runtime, e.g. for
MUSL builds.
Passing them twice resulted in duplicate symbol errors:
```
libtool: link: clang-15 --target=aarch64-unknown-linux-musl [...] /usr/lib/aarch64-linux-musl/crt1.o [...] /usr/lib/aarch64-linux-musl/crt1.o [...]
ld.lld-15: error: duplicate symbol: _start
>>> defined at crt1.c
>>> /usr/lib/aarch64-linux-musl/crt1.o:(.text+0x0)
>>> defined at crt1.c
>>> /usr/lib/aarch64-linux-musl/crt1.o:(.text+0x0)
[...]
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
This behaviour came with commit 1a593191c2
(2013-07-23) as a fix for bug https://curl.haxx.se/bug/view.cgi?id=1217.
The patch was a works-for-me hack that ended up merged in curl:
https://sourceforge.net/p/curl/bugs/1217/#06ef
With the root cause remaining unclear.
Perhaps the SUNPro 12 linker was sensitive to `-L` `-l` order, requiring
`-L` first? This would be unusual and suggests a bug in either the
linker or in `libtool`.
The curl build does pass the list of detected libs via its own
`LIBCURL_LIBS` variable, which ends up before `LDFLAGS` on the `libtool`
command line, but it's the job of `libtool` to ensure that even
a peculiar linker gets the options in the expected order. Also because
autotools passes `LDFLAGS` last, making it hardly possible to pass
anything after it.
Perhaps in the 10 years since this issue, this already got a fix
upstream.
This patch deletes `LDFLAGS` from our customized libcurl options,
leaving a single copy of them as passed by autotools automatically.
Reverts 1a593191c2Closes#12310
To allow passing `LDFLAGS` specific to libcurl (`CURL_LDFLAGS_LIB`) and
curl tool (`CURL_LDFLAGS_BIN`).
This makes it possible to build libcurl and curl with a single
invocation with lib- and tool-specific custom linker flags.
Such flag can be enabling `.map` files, a `.def` file for libcurl DLL,
controlling static/shared, incl. requesting a static curl tool (with
`-static-libtool-libs`) while building both shared and static libcurl.
curl-for-win uses the above and some more.
These options are already supported in `Makefile.mk`. CMake has built-in
variables for this.
Closes#12312
To make it work properly with curl_easy_duphandle(). This, because
duphandle duplicates the entire 'UserDefined' struct by plain copy while
'hstslist' is a linked curl_list of file names. This would lead to a
double-free when the second of the two involved easy handles were
closed.
Closes#12315
- Increase the maximum request method name length from 11 to 23.
For HTTP/1.1 and earlier there's not a specific limit in libcurl for
method length except that it is limited by the initial HTTP request
limit (DYN_HTTP_REQUEST). Prior to fc2f1e54 HTTP/2 was treated the same
and there was no specific limit.
According to Internet Assigned Numbers Authority (IANA) the longest
registered method is UPDATEREDIRECTREF which is 17 characters.
Also there are unregistered methods used by some companies that are
longer than 11 characters.
The limit was originally added by 61f52a97 but not used until fc2f1e54.
Ref: https://www.iana.org/assignments/http-methods/http-methods.xhtml
Closes https://github.com/curl/curl/pull/12311
In recent quiche, transport parameter API is separated
with quiche_conn_peer_transport_params().
(https://github.com/cloudflare/quiche/pull/1575)
It breaks with bulding with latest(post 0.18.0) quiche.
Closes#12180
GCC 14 introduces a new -Walloc-size included in -Wextra which gives:
```
src/tool_operate.c: In function ‘add_per_transfer’:
src/tool_operate.c:213:5: warning: allocation of insufficient size ‘1’ for type ‘struct per_transfer’ with size ‘480’ [-Walloc-size]
213 | p = calloc(sizeof(struct per_transfer), 1);
| ^
src/var.c: In function ‘addvariable’:
src/var.c:361:5: warning: allocation of insufficient size ‘1’ for type ‘struct var’ with size ‘32’ [-Walloc-size]
361 | p = calloc(sizeof(struct var), 1);
| ^
```
The calloc prototype is:
```
void *calloc(size_t nmemb, size_t size);
```
So, just swap the number of members and size arguments to match the
prototype, as we're initialising 1 struct of size `sizeof(struct
...)`. GCC then sees we're not doing anything wrong.
Closes#12292
This patch makes the following changes:
- adds the option `CURL_DISABLE_INSTALL` - to disable 'install' targets.
- Removes the target `curlu` when the option `BUILD_TESTING` is set to
`OFF` - to prevent it from being loaded in Visual Studio.
Closes#12287
Uniformly use `OPENSSL_VERSION_NUMBER` to check for OpenSSL version.
Before this patch some places used `OPENSSL_VERSION_MAJOR`.
Also fix `lib/md4.c`, which included `opensslconf.h`, but that doesn't
define any version number in these implementations: BoringSSL, AWS-LC,
LibreSSL, wolfSSL. (Only in mainline OpenSSL/quictls). Switch that to
`opensslv.h`. This wasn't causing a deeper problem because the code is
looking for v3, which is only provided by OpenSSL/quictls as of now.
According to https://github.com/openssl/openssl/issues/17517, the macro
`OPENSSL_VERSION_NUMBER` is safe to use and not deprecated.
Reviewed-by: Marcel Raad
Closes#12298
Some servers don't support the ALPN protocol "http/1.0" (e.g. IIS 10),
avoid it and use "http/1.1" instead.
This reverts commit df856cb5c9 (#10183).
Fixes#12259Closes#12285
- Pelles C: Unclear status, failed to obtain a fresh copy a few months
ago. Possible website is HTTP-only. ~10 years ago I left this compiler
dealing with crashes and other issues with no response on the forum
for years. It has seen some activity in curl back in 2021.
- LCC: Last stable release in September 2002.
- Salford C: Misses winsock2 support, possibly abandoned? Last mentioned
in 2006.
- Borland C++: We dropped Borland C++ support in 2018.
- MS Visual C++ 6.0: Released in 1998. curl already requires VS 2010
(or possibly 2008) as a minimum.
Closes#12222
We use `stdint.h` unconditionally in all places except one. These uses
are imposed by external dependencies / features. nghttp2, quic, wolfSSL
and `HAVE_MACH_ABSOLUTE_TIME` do require this C99 header. It means that
any of these features make curl require a C99 compiler. (In case of
MSVC, this means Visual Studio 2010 or newer.)
This patch changes the single use of `stdint.h` guarded by
`HAVE_STDINT_H` to use `stdint.h` unconditionally. Also stop using
`inttypes.h` as an alternative there. `HAVE_INTTYPES_H` wasn't used
anywhere else, allowing to delete this feature check as well.
Closes#12275
This PR has these changes:
Renaming of unencode_* to cwriter, e.g. client writers
- documentation of sendf.h functions
- move max decode stack checks back to content_encoding.c
- define writer phase which was used as order before
- introduce phases for monitoring inbetween decode phases
- offering default implementations for init/write/close
Add type paramter to client writer's do_write()
- always pass all writes through the writer stack
- writers who only care about BODY data will pass other writes unchanged
add RAW and PROTOCOL client writers
- RAW used for Curl_debug() logging of CURLINFO_DATA_IN
- PROTOCOL used for updates to data->req.bytecount, max_filesize checks and
Curl_pgrsSetDownloadCounter()
- remove all updates of data->req.bytecount and calls to
Curl_pgrsSetDownloadCounter() and Curl_debug() from other code
- adjust test457 expected output to no longer see the excess write
Closes#12184
autotools unexpectedly detects `arc4random` because it is also looking
into dependency libs. One dependency, LibreSSL, happens to publish an
`arc4random` function (via its shared lib before v3.7, also via static
lib as of v3.8.2). When trying to use this function in `lib/rand.c`,
its protoype is missing. To fix that, curl included a prototype, but
that used a C99 type without including `stdint.h`, causing:
```
../../lib/rand.c:37:1: error: unknown type name 'uint32_t'
37 | uint32_t arc4random(void);
| ^
1 error generated.
```
This patch improves this by dropping the local prototype and instead
limiting `arc4random` use for non-OpenSSL builds. OpenSSL builds provide
their own random source anyway.
The better fix would be to teach autotools to not link dependency libs
while detecting `arc4random`.
LibreSSL publishing a non-namespaced `arc4random` tracked here:
https://github.com/libressl/portable/issues/928
Regression from 755ddbe901#10672
Reviewed-by: Daniel Stenberg
Fixes#12257Closes#12274
This change fixes a compiler warning with gcc-12.2.0 when
`-DCURL_DISABLE_BEARER_AUTH=ON` is used.
/home/tox/src/curl/lib/http.c: In function 'Curl_http_input_auth':
/home/tox/src/curl/lib/http.c:1147:12: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
1147 | ;
| ^
Closes#12262
Since vanilla OpenSSL does not support the QUIC API I think it helps
users to identify the correct OpenSSL fork in version output. The best
(crude) way to do that right now seems to be to check if ngtcp2 support
is enabled.
Closes#12270
- tunnel https proxy used for http: transfers does
no check if proxy-ssl configuration matches
- test cases added, test_10_12 fails on 8.4.0
Closes#12255
- Add these revocation errors to sspi error list:
CRYPT_E_NO_REVOCATION_DLL, CRYPT_E_NO_REVOCATION_CHECK,
CRYPT_E_REVOCATION_OFFLINE and CRYPT_E_NOT_IN_REVOCATION_DATABASE.
Prior to this change those error codes were not matched to their macro
name and instead shown as "unknown error".
Before:
schannel: next InitializeSecurityContext failed:
Unknown error (0x80092013) - The revocation function was
unable to check revocation because the revocation server was offline.
After:
schannel: next InitializeSecurityContext failed:
CRYPT_E_REVOCATION_OFFLINE (0x80092013) - The revocation function was
unable to check revocation because the revocation server was offline.
Bug: https://github.com/curl/curl/issues/12239
Reported-by: Niracler Li
Closes https://github.com/curl/curl/pull/12241
- Use malloc + strncpy instead of Curl_memdup to dupe the string before
null terminating it.
Prior to this change if Curl_strndup was passed a length longer than
the allocated string then it could copy out of bounds.
This change is for posterity. Curl_strndup was added in the parent
commit and currently none of the calls to it pass a length that would
cause it to read past the allocated length of the input.
Follow-up to d3b3ba35.
Closes https://github.com/curl/curl/pull/12254
- perform connection cache matching against `data->set.ssl.primary`
and proxy counterpart
- fully clone connection ssl config only when connection is used
Closes#12237
- disable HTTPS-proxy as well, since it can't work without HTTP
- curl_setup: when HTTP is disabled, also disable all features that are
HTTP-only
- version: HTTPS-proxy only exists if HTTP support exists
Closes#12223
Finding a 'Content-Range:' in the response changed the handling.
Add test case 1475 to verify -C - with 416 and Content-Range: header,
which is almost exactly like test 194 which instead uses a fixed -C
offset. Adjusted test 194 to also be considered fine.
Fixes#10521
Reported-by: Smackd0wn
Fixes#12174
Reported-by: Anubhav Rai
Closes#12176
After this patch we assume availability of `getaddrinfo` and
`freeaddrinfo`, first introduced in Windows XP. Meaning curl
now requires building for Windows XP as a minimum.
TODO: assume these also in autotools.
Ref: https://github.com/curl/curl/pull/12221#issuecomment-1783761806Closes#12225
- On Windows if IPv6 is enabled but getaddrinfo is missing then #error
the build.
curl can be built with IPv6 support (ENABLE_IPV6) but without the
ability to resolve hosts to IPv6 addresses (HAVE_GETADDRINFO). On
Windows this is highly unlikely and should be considered a bad build
configuration.
Such a bad configuration has already given us a bug that was hard to
diagnose. See #12134 and #12136 for discussion.
Ref: https://github.com/curl/curl/issues/12134
Ref: https://github.com/curl/curl/pull/12136
Closes https://github.com/curl/curl/pull/12221
- If CURLSSLOPT_NATIVE_CA on Windows then import from intermediate CA
"CA" store after importing from root CA "ROOT" store.
This change allows curl to work in situations where a server does not
send all intermediate certs and they are present in the "CA" store (the
store with intermediate CAs). This is already allowed by the Schannel
backend.
Also this change makes partial chain verification possible for those
certs since we allow partial chain verification by default for OpenSSL
(unless CURLSSLOPT_NO_PARTIALCHAIN). This is not allowed by the Schannel
backend.
Prior to this change CURLSSLOPT_NATIVE_CA only imported "ROOT" certs.
Fixes https://github.com/curl/curl/issues/12155
Closes https://github.com/curl/curl/pull/12185
In 8.4.0 we deleted `_mingw.h` as part of purging old-mingw support.
Turns out `_mingw.h` had the side-effect of setting a default
`_WIN32_WINNT` value expected by `lib/config-win32.h` to enable
`getaddrinfo` support in `Makefile.mk` mingw-w64 builds. This caused
disabling support for this unless specifying the value manually.
Restore this header and update its comment to tell why we continue
to need it.
This triggered a regression in official Windows curl builds starting
with 8.4.0_1. Fixed in 8.4.0_6. (8.5.0 will be using CMake.)
Regression from 38029101e2#11625
Reported-by: zhengqwe on github
Helped-by: Nico Rieck
Fixes#12134Fixes#12136Closes#12217
