- return error on zero length input
- return error on OOM or doing too large output
- fix full 32-bit number support
- fix the broken handling of the first and second numbers
- support up to 32-bit minus 80 for the second number
- a field with a leading 0x80 is now considered an error, since it only
works as padding and is then no longer the shortest possible version
Add unit tests in 1666
Bonus: removed the last argument to OID2str() as it was always set TRUE.
Closes#21003
It was incorrecly loaded with env `CURL_CA_BUNDLE` unset +
`SSL_CERT_DIR` set + `SSL_CERT_FILE` unset.
Found by Codex Security
Follow-up to 29bce9857a#11325#11531Closes#20989
Curl_1st_err() does not return the second error if the first result is
CURLE_AGAIN. This may cause errors to not become noticeable when they
should be.
Replace all use of Curl_1st_err() with Curl_1st_fatal(), which handles
CURLE_AGAIN as a not-a-real-error case.
Closes#20980
Extend `#pragma diagnostic push`/`pop` guards to the whole codebase
(from tests and examples only) to disable it for GCC <4.6. Rename guard
to `CURL_HAVE_DIAG` and make it include llvm/clang to be interchangeable
with `__GNUC__ || __clang__` in this context.
The above means no longer disabling certain warnings locally, so pair
this with disabling all picky warnings for GCC <4.6.
Also:
- drop global workarounds for misbehaving GCC <4.6 compiler warnings.
Not needed with picky warnings disabled.
Reported-by: fds242 on github
Reported-by: Sergey Fedorov
Thanks-to: Orgad Shaneh
Follow-up to f07a98ae11#20366Fixes#20892Fixes#20924Closes#20902Closes#20907
A malicious or compromised FTP server could include control characters
(e.g. bare \r, or bytes 0x01-0x1f/0x7f) inside the quoted directory path
of its 257 PWD response. That string is stored verbatim as
ftpc->entrypath and later sent unescaped in a CWD command on connection
reuse via Curl_pp_sendf(), which performs no sanitization before
appending \r\n.
Reject the entire path if any control character is encountered during
extraction so that tainted data never reaches a subsequent FTP command.
Add test case 3217 and 3218 to verify. Adjusted test 1152 accordingly.
Closes#20949
Paths starting with one or two leading dots but without a following
slash were not handled correctly.
Follow-up to c31dd6631f
Extended test 1395 accordingly with a set of new test string.
Reported by Codex Security
Closes#20974
When errorf()/warnf() is used early on, before the global pointer is
setup, curl would previosly deref the null pointer.
Follow-up to 3b40128b0f
Found by Codex Security
Closes#20967
The read_field_headers() function would return "ok" even if the
underlying file read returned error, thus would the parent not become
aware of the problem.
Follow-up to f847d2ed02
Found by Codex Security
Closes#20963
The extra % translates to nothing, so this did not break anything they
are just superfluous.
Follow-up to 57d349fe0e
Assisted-by: Viktor Szakats
Found by Codex Security
uidvalidity_set and mb_uidvalidity_set flags were never reset, leaving a
risk for stale UIDVALIDITY state across transfers and mailbox switches.
Follow-up to fb6a4802d7
Spotted by Codex Security
Closes#20962
Missing ferror handling in Curl_get_line causes infinite loops on I/O
errors, leading to denial-of-service hangs for config/cache file loads.
Follow-up to 769ccb4d42
Pointed out by Codex Security
Closes#20958
Introduce `Curl_xfer_is_secure(data)` that returns TRUE for transfers
that happen(ed) over a end-to-end secured connection, e.g. SSL.
Add test1586 to verify behaviour for http: transfers via a https: proxy.
Reported-by: lg_oled77c5pua on hackerone
Closes#20951
When .curlrc is parsed successfully but the tool exits early before
parse_args() executes; the allocated path was not freed.
Spotted by Codex Security
Closes#20954
In curlx_strerror on Windows, the condition checks `!strerror_s(...)`
(true on success) and therefore always evaluates the fallback block.
Even when strerror_s successfully produced a valid errno message.
Follow-up to 1eca08a541
Pointed out by Codex Security
Closes#20955
ngtcp2 1.14.0 added module dependencies to `ngtcp2_crypto_*.pc` files.
This broke certain build cases in curl, because configure was is
querying pkg-config modules by setting `PKG_CONFIG_LIBDIR` to the
directory specified via `--with-*=` options, including `--with-ngtcp2=`.
Setting `PKG_CONFIG_LIBDIR` tells pkg-config (and pkgconf) to ignore
system locations. This caused that `ngtcp2_crypto_gnutls.pc` could no
longer find its indirect dependencies, if those were present at system
locations (where they typically are). Another fallout was BoringSSL,
because it does not provide `openssl.pc` on its own, and successful
detection relied on finding a non-BoringSSL copy, typically at a system
location (also fixed in ngtcp2 main branch).
Fix `ngtcp2_crypto_*` detections to not touch `PKG_CONFIG_LIBDIR` and
instead prepend `<path>` set via `--with-ngtcp2=` to `PKG_CONFIG_PATH`.
This ensures to pick up any dependent modules from system locations.
Note the side-effect is that potentially undesired modules may be
detected this way from system locations, i.e. it makes this particular
detection less "hermetic" than the rest used in curl configure.
(Configurations using a bare `--with-ngtcp2` with no path were not
affected, and served as a workaround before this patch. It remains a
valid way of configuration after.)
Both `pkgconf` and `pkg-config` use this logic to calculate their search
directory list:
```pseudo
search = {}
if PKG_CONFIG_PATH is set
search += PKG_CONFIG_PATH
endif
if PKG_CONFIG_LIBDIR is set (even if empty)
search += PKG_CONFIG_LIBDIR
else
search += built-in-pkg-config-dirs
endif
```
Refs:
https://github.com/curl/curl/pull/18028/commits (earlier attempt. Failed due to using `PKG_CONFIG_DIR` instead of the correct `PKG_CONFIG_PATH`)
https://github.com/curl/curl/pull/18028/commits/c0874ce8242d42a1ae1d570d6b70b8360da56482https://man.archlinux.org/man/pkgconf.1.enhttps://manpages.debian.org/unstable/pkgconf/pkgconf.1.en.htmlhttps://manpages.debian.org/unstable/pkg-config/pkg-config.1.en.html10e27fd63c
Bug: https://github.com/curl/curl/pull/18022#issuecomment-3120587041
Bug: https://github.com/ngtcp2/ngtcp2/pull/1689#issuecomment-3120593664
Follow-up to 04d90b5deb#20931
Follow-up to 3c64ffaff4#18415#18188
Follow-up to 99500660af#18028#18022Closes#20920
The `ISLOWHEXALHA` and `ISUPHEXALHA` macros were introduced in commit
f65f750 and seem to be only referenced locally by the `ISXDIGIT` macro.
Judging by the `ISALPHA` macro defined in the same file, it seems like
the intention was to spell them as `IS.*HEXALPHA`.
I noticed this while reading through the code and decided to open a PR,
even if it is only a tiny change, just because I was already looking at
it and it might be useful. If there is any reason not to merge this,
please do close the PR.
Closes#20810
