Age | Commit message (Collapse) | Author |
|
Reported-by: Peter Wu
Closes #2654
|
|
Closes #2653
|
|
The struct field is never set (since 5e0d9aea3) so remove the use of it
and remove the connectdata pointer from the prototype.
Reported-by: Tejas
Bug: https://curl.haxx.se/mail/lib-2018-06/0054.html
Closes #2647
|
|
with clang-6.0:
```
vtls/schannel_verify.c: In function 'add_certs_to_store':
vtls/schannel_verify.c:212:30: warning: passing argument 11 of 'CryptQueryObject' from incompatible pointer type [-Wincompatible-pointer-types]
&cert_context)) {
^
In file included from /usr/share/mingw-w64/include/schannel.h:10:0,
from /usr/share/mingw-w64/include/schnlsp.h:9,
from vtls/schannel.h:29,
from vtls/schannel_verify.c:40:
/usr/share/mingw-w64/include/wincrypt.h:4437:26: note: expected 'const void **' but argument is of type 'CERT_CONTEXT ** {aka struct _CERT_CONTEXT **}'
WINIMPM WINBOOL WINAPI CryptQueryObject (DWORD dwObjectType, const void *pvObject, DWORD dwExpectedContentTypeFlags, DWORD dwExpectedFormatTypeFlags, DWORD dwFlags,
^~~~~~~~~~~~~~~~
```
Ref: https://msdn.microsoft.com/library/windows/desktop/aa380264
Closes https://github.com/curl/curl/pull/2648
|
|
Given the contstraints of SChannel, I'm exposing these as the algorithms
themselves instead; while replicating the ciphersuite as specified by
OpenSSL would have been preferable, I found no way in the SChannel API
to do so.
To use this from the commandline, you need to pass the names of contants
defining the desired algorithms. For example, curl --ciphers
"CALG_SHA1:CALG_RSA_SIGN:CALG_RSA_KEYX:CALG_AES_128:CALG_DH_EPHEM"
https://github.com The specific names come from wincrypt.h
Closes #2630
|
|
- Get rid of variable that was generating false positive warning
(unitialized)
- Fix issues in tests
- Reduce scope of several variables all over
etc
Closes #2631
|
|
Previously it was checked for in configure/cmake, but that would then
leave other build systems built without engine support.
While engine support probably existed prior to 1.0.1, I decided to play
safe. If someone experience a problem with this, we can widen the
version check.
Fixes #2641
Closes #2644
|
|
Fixes the build problem when both boringssl and schannel are enabled.
Fixes #2634
Closes #2643
|
|
Closes #2640
|
|
Detected using the `codespell` tool (version 1.13.0).
Also secure and fix an URL.
|
|
|
|
URL: https://curl.haxx.se/mail/lib-2018-06/0000.html
This is step one. It adds #error statements that require source edits to
make curl build again if asked to use axTLS. At a later stage we might
remove the axTLS specific code completely.
Closes #2628
|
|
According to the user survey 2018, not even one out of 670 users use
them. Nobody on the mailing list spoke up for them either.
Closes #2629
|
|
... for curl_dofreeaddrinfo
|
|
... it might call infof() with a NULL first argument that isn't harmful
but makes it not do anything. The infof() line is not very useful
anymore, it has served it purpose. Good riddance!
Fixes #2627
|
|
If there's an existing entry using the selected name.
Closes #2622
|
|
If configure detects fnmatch to be available, use that instead of our
custom one for FTP wildcard pattern matching. For standard compliance,
to reduce our footprint and to use already well tested and well
exercised code.
A POSIX fnmatch behaves slightly different than the internal function
for a few test patterns currently and the macOS one yet slightly
different. Test case 1307 is adjusted for these differences.
Closes #2626
|
|
On our x86 Android toolchain, getpwuid_r is implemented but the header
is missing:
netrc.c:81:7: error: implicit declaration of function 'getpwuid_r' [-Werror=implicit-function-declaration]
Unfortunately, the function is used in curl_ntlm_wb.c, too, so I moved
the prototype to curl_setup.h.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
Closes #2609
|
|
Closes #2623
|
|
Adds CURLOPT_DISALLOW_USERNAME_IN_URL and --disallow-username-in-url. Makes
libcurl reject URLs with a username in them.
Closes #2340
|
|
Adds CURLOPT_TLS13_CIPHERS and CURLOPT_PROXY_TLS13_CIPHERS.
curl: added --tls13-ciphers and --proxy-tls13-ciphers
Fixes #2435
Reported-by: zzq1015 on github
Closes #2607
|
|
A non-escaped bracket ([) is for a character group - as documented. It
will *not* match an individual bracket anymore. Test case 1307 updated
accordingly to match.
Problem detected by OSS-Fuzz, although this fix is probably not a final
fix for the notorious timeout issues.
Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8525
Closes #2614
|
|
The latest psl is cached in the multi or share handle. It is refreshed
before use after 72 hours.
New share lock CURL_LOCK_DATA_PSL controls the psl cache sharing.
If the latest psl is not available, the builtin psl is used.
Reported-by: Yaakov Selkowitz
Fixes #2553
Closes #2601
|
|
The autotools-based build system does it, so we do it also in CMake.
Bug: #2609
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
|
|
Closes #2604
|
|
Fallback on Z_SYNC_FLUSH when Z_BLOCK is not available.
Fixes #2606
Closes #2608
|
|
... even when there's no protocol specific handler setup.
Bug: https://curl.haxx.se/mail/lib-2018-05/0062.html
Reported-by: Sean Miller
Closes #2600
|
|
Closes #2102
|
|
using -DCMAKE_DEBUG_POSTFIX explicitly
fixes #2121, obsoletes #2384
|
|
This avoids appending error data to already existing good data.
Test 92 is updated to match this change.
New test 1156 checks all combinations of --range/--resume, --fail,
Content-Range header and http status code 200/416.
Fixes #1163
Reported-By: Ithubg on github
Closes #2578
|
|
|
|
OpenSSL has supported --cacert for ages, always accepting LF-only line
endings ("Unix line endings") as well as CR/LF line endings ("Windows
line endings").
When we introduced support for --cacert also with Secure Channel (or in
cURL speak: "WinSSL"), we did not take care to support CR/LF line
endings, too, even if we are much more likely to receive input in that
form when using Windows.
Let's fix that.
Happily, CryptQueryObject(), the function we use to parse the ca-bundle,
accepts CR/LF input already, and the trailing LF before the END
CERTIFICATE marker catches naturally any CR/LF line ending, too. So all
we need to care about is the BEGIN CERTIFICATE marker. We do not
actually need to verify here that the line ending is CR/LF. Just
checking for a CR or an LF is really plenty enough.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Closes https://github.com/curl/curl/pull/2592
|
|
... and unify the source code to adhere.
Closes #2563
|
|
The previous limit of 5 can still end up in situation that takes a very
long time and consumes a lot of CPU.
If there is still a rare use case for this, a user can provide their own
fnmatch callback for a version that allows a larger set of wildcards.
This commit was triggered by yet another OSS-Fuzz timeout due to this.
Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8369
Closes #2587
|
|
...as there's also a version 2.
Closes #2579
|
|
Provide a set of new timers that return the time intervals using integer
number of microseconds instead of floats.
The new info names are as following:
CURLINFO_APPCONNECT_TIME_T
CURLINFO_CONNECT_TIME_T
CURLINFO_NAMELOOKUP_TIME_T
CURLINFO_PRETRANSFER_TIME_T
CURLINFO_REDIRECT_TIME_T
CURLINFO_STARTTRANSFER_TIME_T
CURLINFO_TOTAL_TIME_T
Closes #2495
|
|
... previously it only used the max setting if a TLS version was also
explicitly asked for.
Reported-by: byte_bucket
Fixes #2571
Closes #2572
|
|
|
|
|
|
.. because original MinGW and old compilers do not have the Windows API
definitions needed to support manual verification.
|
|
Original MinGW targets Windows 2000 by default, which lacks some APIs and
definitions for this feature. Disable it if these APIs are not available.
Closes https://github.com/curl/curl/pull/2522
|
|
Closes #2570
|
|
|
|
Reported-by: Rikard Falkeborn
Bug: #2560
Closes #2569
|
|
Fixes gcc-8 picky compiler warnings
Reported-by: Rikard Falkeborn
Bug: #2560
Closes #2568
|
|
|
|
|
|
When there's an upload in progress, make sure to wait for the socket to
become writable.
Detected-by: steini2000 on github
Bug: #2520
Closes #2567
|
|
Response data for a handle with a large buffer might be cached and then
used with the "closure" handle when it has a smaller buffer and then the
larger cache will be copied and overflow the new smaller heap based
buffer.
Reported-by: Dario Weisser
CVE: CVE-2018-1000300
Bug: https://curl.haxx.se/docs/adv_2018-82c2.html
|
|
... leaving the k->str could lead to buffer over-reads later on.
CVE: CVE-2018-1000301
Assisted-by: Max Dymond
Detected by OSS-Fuzz.
Bug: https://curl.haxx.se/docs/adv_2018-b138.html
Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7105
|