- 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
