- Define USE_WIN32_CRYPTO by default. This enables SMB.
- Show whether SMB is enabled in the "Enabled features" output.
- Fix mingw compiler warning for call to CryptHashData by casting away
const param. mingw CryptHashData prototype is wrong.
Closes https://github.com/curl/curl/pull/4717
The code was duplicated in the various resolver backends.
Also, it was called after the call to `Curl_ipvalid`, which matters in
case of `CURLRES_IPV4` when called from `connect.c:bindlocal`. This
caused test 1048 to fail on classic MinGW.
The code ignores `conn->ip_version` as done previously in the
individual resolver backends.
Move the call to the `resolver_start` callback up to appease test 655,
which wants it to be called also for literal addresses.
Closes https://github.com/curl/curl/pull/4798
- When creating a directory hierarchy do not error when mkdir fails due
to error EACCESS (13) "access denied".
Some file systems allow for directory traversal; in this case that it
should be possible to create child directories when permission to the
parent directory is restricted.
This is a regression caused by me in f16bed0 (precedes curl-7_61_1).
Basically I had assumed that if a directory already existed it would
fail only with error EEXIST, and not error EACCES. The latter may
happen if the directory exists but has certain restricted permissions.
Reported-by: mbeifuss@users.noreply.github.com
Fixes https://github.com/curl/curl/issues/4796
Closes https://github.com/curl/curl/pull/4797
When using randomized features of runtests (-R and --shallow) it is
useful to have a fixed random seed to make sure for example extra
commits in a branch or a rebase won't change the seed that would make
repeated runs work differently.
As it is also useful to change seed sometimes, the default seed is now
determined based on the current month (and first line curl -V
output). When the month changes, so will the random seed.
The specific seed is also shown in the standard test suite top header
and it can be set explictly with the new --seed=[num] option so that the
exact order of a previous run can be achieved.
Closes#4734
It was removed for output containing ' =' via `s/ =.*//`. With classic
MinGW, this made lines with `free()` end with CRLF, but lines with e.g.
`malloc()` end with only LF. The tests expect LF only.
Closes https://github.com/curl/curl/pull/4788
Previously it would end up with an uninitialized memory buffer that
would lead to a crash or junk getting output.
Added test 1271 to verify.
Reported-by: Brian Carpenter
Closes#4786
Prior to this change the swsbounce check in service_connection could
fail because prevtestno and prevpartno were not set, which would cause
the wrong response data to be sent to some tests and cause them to fail.
Ref: https://github.com/curl/curl/pull/4717#issuecomment-570240785
Prior to this change tests that required NTLM feature did not require
SSL feature.
There are pending changes to cmake builds that will allow enabling NTLM
in non-SSL builds in Windows. In that case the NTLM auth strings created
are different from what is expected by the NTLM tests and they fail:
"The issue with NTLM is that previous non-SSL builds would not enable
NTLM and so the NTLM tests would be skipped."
Assisted-by: marc-groundctl@users.noreply.github.com
Ref: https://github.com/curl/curl/pull/4717#issuecomment-566218729
Closes https://github.com/curl/curl/pull/4768
Factor out common I/O loop as bearssl_run_until, which reads/writes TLS
records until the desired engine state is reached. This is now used for
the handshake, read, write, and close.
Match OpenSSL SSL_write behavior, and don't return the number of bytes
written until the corresponding records have been completely flushed
across the socket. This involves keeping track of the length of data
buffered into the TLS engine, and assumes that when CURLE_AGAIN is
returned, the write function will be called again with the same data
and length arguments. This is the same requirement of SSL_write.
Handle TLS close notify as EOF when reading by returning 0.
Closes https://github.com/curl/curl/pull/4748
- Undefine DEBUGASSERT in curl_setup_once.h in case it was already
defined as a system macro.
- Don't compile write32_le in curl_endian unless
CURL_SIZEOF_CURL_OFF_T > 4, since it's only used by Curl_write64_le.
- Include <arpa/inet.h> in socketpair.c.
Closes https://github.com/curl/curl/pull/4756
For compatibility with `fwrite`, the `CURLOPT_HEADERFUNCTION` callback
is passed two `size_t` parameters which, when multiplied, designate the
number of bytes of data passed in. In practice, CURL always sets the
first parameter (`size`) to 1.
This practice is also enshrined in documentation and cannot be changed
in future. The documentation states that the default callback is
`fwrite`, which means `fwrite` must be a suitable function for this
purpose. However, the documentation also states that the callback must
return the number of *bytes* it successfully handled, whereas ISO C
`fwrite` returns the number of items (each of size `size`) which it
wrote. The only way these numbers can be equal is if `size` is 1.
Since `size` is 1 and can never be changed in future anyway, document
that fact explicitly and let users rely on it.
Reported-by: Frank Gevaerts
Commit-message-by: Christopher Head
Ref: https://github.com/curl/curl/pull/2787
Fixes https://github.com/curl/curl/issues/4758
The comment was confusing and suggested that setting CURLOPT_NOPROGRESS
to 0L would both enable and disable debug output at the same time, like
a Schrödinger's cat of CURLOPTs.
Closes#4745
- Remove our cb_update_key in favor of ngtcp2's new
ngtcp2_crypto_update_key_cb which does the same thing.
Several days ago the ngtcp2_update_key callback function prototype was
changed in ngtcp2/ngtcp2@42ce09c. Though it would be possible to
fix up our cb_update_key for that change they also added
ngtcp2_crypto_update_key_cb which does the same thing so we'll use that
instead.
Ref: https://github.com/ngtcp2/ngtcp2/commit/42ce09c
Closes https://github.com/curl/curl/pull/4735
Even if the initial request line wasn't found. With the fix to 1455, the
test number is now detected correctly.
(Problem found when running tests in random order.)
Closes#4744
