- Feb 05, 2016
-
-
Jay Satiro authored
- Add unit test 1604 to test the sanitize_file_name function. - Use -DCURL_STATICLIB when building libcurltool for unit testing. - Better detection of reserved DOS device names. - New flags to modify sanitize behavior: SANITIZE_ALLOW_COLONS: Allow colons SANITIZE_ALLOW_PATH: Allow path separators and colons SANITIZE_ALLOW_RESERVED: Allow reserved device names SANITIZE_ALLOW_TRUNCATE: Allow truncating a long filename - Restore sanitization of banned characters from user-specified outfile. Prior to this commit sanitization of a user-specified outfile was temporarily disabled in 2b6dadc5 because there was no way to allow path separators and colons through while replacing other banned characters. Now in such a case we call the sanitize function with SANITIZE_ALLOW_PATH which allows path separators and colons to pass through. Closes https://github.com/curl/curl/issues/624 Reported-by: Octavio Schroeder
-
- Feb 04, 2016
-
-
Viktor Szakats authored
-
Jay Satiro authored
Free an existing domain before replacing it. Bug: https://github.com/curl/curl/issues/635 Reported-by: <silveja1@users.noreply.github.com>
-
Viktor Szakats authored
Closes #632
-
- Feb 03, 2016
-
-
Daniel Stenberg authored
I removed the scheme prefix from the URLs references this host name, as we don't own/run that anymore but the name is kept for historic reasons.
-
Daniel Stenberg authored
-
Viktor Szakats authored
-
Dan Fandrich authored
-
- Feb 02, 2016
-
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
Daniel Stenberg authored
It isn't used by the code in current conditions but for safety it seems sensible to at least not crash on such input. Extended unit test 1395 to verify this too as well as a plain "/" input.
-
- Feb 01, 2016
-
-
Daniel Stenberg authored
-
Sergei Nikulov authored
Closes #621
-
Jay Satiro authored
Due to path separators being incorrectly sanitized in --output pathnames, eg -o c:\foo => c__foo This is a partial revert of 3017d8a8 until I write a proper fix. The remote-name will continue to be sanitized, but if the user specified an --output with string replacement (#1, #2, etc) that data is unsanitized until I finish a fix. Bug: https://github.com/bagder/curl/issues/624 Reported-by: Octavio Schroeder
-
- Jan 29, 2016
-
-
Jay Satiro authored
.. also warn about letting the server pick the filename.
-
Gisle Vanem authored
-
- Jan 28, 2016
-
-
Daniel Stenberg authored
-
Sergei Nikulov authored
Closes #617
-
Sergei Nikulov authored
Closes https://github.com/bagder/curl/pull/618
-
Viktor Szakats authored
tool_doswin.c:185:14: warning: 'msdosify' defined but not used [-Wunused-function] Closes https://github.com/bagder/curl/pull/616
-
- Jan 27, 2016
-
-
Daniel Stenberg authored
Reported-by: Bernard Spil
-
Daniel Stenberg authored
-
- Jan 26, 2016
-
-
Daniel Stenberg authored
-
Isaac Boukris authored
Proxy NTLM authentication should compare credentials when re-using a connection similar to host authentication, as it authenticate the connection. Example: curl -v -x http://proxy:port http://host/ -U good_user:good_pwd --proxy-ntlm --next -x http://proxy:port http://host/ [-U fake_user:fake_pwd --proxy-ntlm] CVE-2016-0755 Bug: http://curl.haxx.se/docs/adv_20160127A.html
-
Ray Satiro authored
curl does not sanitize colons in a remote file name that is used as the local file name. This may lead to a vulnerability on systems where the colon is a special path character. Currently Windows/DOS is the only OS where this vulnerability applies. CVE-2016-0754 Bug: http://curl.haxx.se/docs/adv_20160127B.html
-
Daniel Stenberg authored
-
- Jan 25, 2016
-
-
Daniel Stenberg authored
-
- Jan 24, 2016
-
-
paulehoffman authored
Current FAQ didn't make it clear where the main repo is. Closes #612
-
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
- Jan 21, 2016
-
-
Steve Holme authored
-
- Jan 18, 2016
-
-
Jay Satiro authored
- Switch from verifying a pinned public key in a callback during the certificate verification to inline after the certificate verification. The callback method had three problems: 1. If a pinned public key didn't match, CURLE_SSL_PINNEDPUBKEYNOTMATCH was not returned. 2. If peer certificate verification was disabled the pinned key verification did not take place as it should. 3. (related to #2) If there was no certificate of depth 0 the callback would not have checked the pinned public key. Though all those problems could have been fixed it would have made the code more complex. Instead we now verify inline after the certificate verification in mbedtls_connect_step2. Ref: http://curl.haxx.se/mail/lib-2016-01/0047.html Ref: https://github.com/bagder/curl/pull/601
-
Jay Satiro authored
Because disabling the peer verification (--insecure) must not disable the public key pinning check (--pinnedpubkey).
-
- Jan 17, 2016
-
-
Daniel Schauenberg authored
-
- Jan 15, 2016
-
-
Kamil Dudka authored
The CURLOPT_SSH_PUBLIC_KEYFILE option has been documented to handle empty strings specially since curl-7_25_0-31-g05a443a but the behavior was unintentionally removed in curl-7_38_0-47-gfa7d04f. This commit restores the original behavior and clarifies it in the documentation that NULL and "" have both the same meaning when passed to CURLOPT_SSH_PUBLIC_KEYFILE. Bug: http://curl.haxx.se/mail/lib-2016-01/0072.html
-
- Jan 14, 2016
-
-
Daniel Stenberg authored
-
Daniel Stenberg authored
... by extracting the LIB + REASON from the OpenSSL error code. OpenSSL 1.1.0+ returned a new func number of another cerfificate fail so this required a fix and this is the better way to catch this error anyway.
-
Daniel Stenberg authored
-