Wyatt OʼDay reported in #7385 that mbedTLS isn't backwards compatible
and curl no longer builds with it. Document the need to fix our support
until so has been done.
Closes#7390Fixes#7385
Reported-by: Wyatt OʼDay
Reviewed-by: Jay Satiro <raysatiro@yahoo.com>
Only the OpenSSL backend actually use the EGDSOCKET, and also use
TLS consistently rather than mixing SSL and TLS. While there, also
fix a minor spelling nit.
Closes: #7391
Reviewed-by: Jay Satiro <raysatiro@yahoo.com>
The documentation for the read callback was erroneously referencing
the nitems argument by nmemb. The error was introduced in commit
ce0881edee.
Closes#7383
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
The reverted commit introduced a logic error in code that was
correct.
The client using libcurl would notice the error since FTP file
uploads in active transfer mode would somtimes complete with
success despite no transfer having been performed and the
"uploaded" file thus not being on the remote server afterwards.
The FTP server would notice the error because it receives a
RST on the data connection it has established with the client
before any data was transferred at all.
The logic error happens if the STOR response from the server have
arrived by the time ftp_multi_statemach() in the affected code path
is called, but the incoming data connection have not arrived yet.
In that case, the processing of the STOR response will cause
'ftpc->wait_data_conn' to be set to TRUE, contradicting the comment
in the code. Since 'complete' will also be set, later logic would
believe the transfer was done.
In most cases, the STOR response will not have arrived yet when
the affected code path is executed, or the incoming connection will
also have arrived, and thus the error would not express itself.
But if the speed difference of the device using libcurl and the
FTP server is exactly right, the error may happen as often as in
one out of hundred file transfers.
This reverts commit 49f3117a23.
Bug: https://curl.se/mail/lib-2021-07/0025.htmlCloses#7362
- the data needs to be "line-based" anyway since it's also passed to the
debug callback/application
- it makes infof() work like failf() and consistency is good
- there's an assert that triggers on newlines in the format string
- Also removes a few instances of "..."
- Removes the code that would append "..." to the end of the data *iff*
it was truncated in infof()
Closes#7357
The API is soon two years old and deserves being shown as the primary
way to drive multi code as it makes it much easier to write code.
multi-poll: removed
multi-legacy: add to show how we did multi API use before
curl_multi_wait/poll.
Closes#7352
Follow-up to 84d2839740 which changed the resolving to always resolve
both address families, but since SOCKS4 only supports IPv4 it should
scan for and use the first available IPv4 address.
Reported-by: shithappens2016 on github
Fixes#7345Closes#7346
The same callback code is used in:
imap-append.c
smtp-authzid.c
smtp-mail.c
smtp-multi.c
smtp-ssl.c
smtp-tls.c
It should not assume that it can copy full lines into the buffer as it
will encourage sloppy coding practices. Instead use byte-wise logic and
check/acknowledge the buffer size appropriately.
Reported-by: Harry Sintonen
Fixes#7330Closes#7331
... when converting a curl_off_t to size_t, by using
CURL_ZERO_TERMINATED before passing the argument to the function.
Detected by Coverity CID 1486590.
Closes#7328
Assisted-by: Daniel Gustafsson
Coverity (CID 1486645) pointed out a use of curl_url_get() in the
parse_proxy function where the return code wasn't checked. A
(void)-prefix makes the intention obvious.
Closes#7320
Follow-up to 6d972c8b1c which missed updating this directory name.
Also no longer call it crustls in the docs and bump to rusttls-ffi 0.7.1
Closes#7311
- Don't set the size of the piece of data to send to the rate limit if
that limit is larger than the buffer size that will hold the piece.
Prior to this change if CURLOPT_MAX_SEND_SPEED_LARGE
(curl tool: --limit-rate) was set then it was possible that a temporary
buffer used for uploading could be written to out of bounds. A likely
scenario for this would be a non-trivial amount of post data combined
with a rate limit larger than CURLOPT_UPLOAD_BUFFERSIZE (default 64k).
The bug was introduced in 24e469f which is in releases since 7.76.0.
perl -e "print '0' x 200000" > tmp
curl --limit-rate 128k -d @tmp httpbin.org/post
Reported-by: Richard Marion
Fixes https://github.com/curl/curl/issues/7308
Closes https://github.com/curl/curl/pull/7315
t.artikov