| Age | Commit message (Collapse) | Author |
|---|
|
Ref: https://github.com/curl/curl/pull/1064#issuecomment-260052409
|
|
Adds access to the effectively used protocol/scheme to both libcurl and
curl, both in string and numeric (CURLPROTO_*) form.
Note that the string form will be uppercase, as it is just the internal
string.
As these strings are declared internally as const, and all other strings
returned by curl_easy_getinfo() are de-facto const as well, string
handling in getinfo.c got const-ified.
Closes #1137
|
|
|
|
|
|
* HTTPS proxies:
An HTTPS proxy receives all transactions over an SSL/TLS connection.
Once a secure connection with the proxy is established, the user agent
uses the proxy as usual, including sending CONNECT requests to instruct
the proxy to establish a [usually secure] TCP tunnel with an origin
server. HTTPS proxies protect nearly all aspects of user-proxy
communications as opposed to HTTP proxies that receive all requests
(including CONNECT requests) in vulnerable clear text.
With HTTPS proxies, it is possible to have two concurrent _nested_
SSL/TLS sessions: the "outer" one between the user agent and the proxy
and the "inner" one between the user agent and the origin server
(through the proxy). This change adds supports for such nested sessions
as well.
A secure connection with a proxy requires its own set of the usual SSL
options (their actual descriptions differ and need polishing, see TODO):
--proxy-cacert FILE CA certificate to verify peer against
--proxy-capath DIR CA directory to verify peer against
--proxy-cert CERT[:PASSWD] Client certificate file and password
--proxy-cert-type TYPE Certificate file type (DER/PEM/ENG)
--proxy-ciphers LIST SSL ciphers to use
--proxy-crlfile FILE Get a CRL list in PEM format from the file
--proxy-insecure Allow connections to proxies with bad certs
--proxy-key KEY Private key file name
--proxy-key-type TYPE Private key file type (DER/PEM/ENG)
--proxy-pass PASS Pass phrase for the private key
--proxy-ssl-allow-beast Allow security flaw to improve interop
--proxy-sslv2 Use SSLv2
--proxy-sslv3 Use SSLv3
--proxy-tlsv1 Use TLSv1
--proxy-tlsuser USER TLS username
--proxy-tlspassword STRING TLS password
--proxy-tlsauthtype STRING TLS authentication type (default SRP)
All --proxy-foo options are independent from their --foo counterparts,
except --proxy-crlfile which defaults to --crlfile and --proxy-capath
which defaults to --capath.
Curl now also supports %{proxy_ssl_verify_result} --write-out variable,
similar to the existing %{ssl_verify_result} variable.
Supported backends: OpenSSL, GnuTLS, and NSS.
* A SOCKS proxy + HTTP/HTTPS proxy combination:
If both --socks* and --proxy options are given, Curl first connects to
the SOCKS proxy and then connects (through SOCKS) to the HTTP or HTTPS
proxy.
TODO: Update documentation for the new APIs and --proxy-* options.
Look for "Added in 7.XXX" marks.
|
|
|
|
Fixes test 1139 failures
Follow-up to f82bbe01c8835
|
|
Brought in ee4f76606cf
Added test case 1280 to verify
Reported-by: Dave Reisner
Bug: https://github.com/curl/curl/commit/ee4f76606cfa4ee068bf28edd37c8dae7e8db317#commitcomment-19823146
|
|
Exit with an error on the first transfer error instead of continuing to
do the rest of the URLs.
Discussion: https://curl.haxx.se/mail/archive-2016-11/0038.html
|
|
to consider ECONNREFUSED as a transient error.
Closes #1064
|
|
Fully implemented with the NSS backend only for now.
Reviewed-by: Ray Satiro
|
|
We're mostly saying just "curl" in lower case these days so here's a big
cleanup to adapt to this reality. A few instances are left as the
project could still formally be considered called cURL.
|
|
Now showing microsecond resolution.
Closes #1106
|
|
... and now it avoids using the libcurl toupper() function
|
|
As they are after all part of the public API. Saves space and reduces
complexity. Remove the strcase defines from the curlx_ family.
Suggested-by: Dan Fandrich
Idea: https://curl.haxx.se/mail/lib-2016-10/0136.html
|
|
Follow-up to 811a693b
|
|
These two public functions have been mentioned as deprecated since a
very long time but since they are still part of the API and ABI we need
to keep them around.
|
|
We had some confusions on when each function was used. We should not act
differently on different locales anyway.
|
|
... to make it less likely that we forget that the function actually
does case insentive compares. Also replaced several invokes of the
function with a plain strcmp when case sensitivity is not an issue (like
comparing with "-").
|
|
... which previously would lead to out of boundary reads.
Reported-by: Luật Nguyễn
|
|
|
|
CVE-2016-8620
Bug: https://curl.haxx.se/docs/adv_20161102F.html
Reported-by: Luật Nguyễn
|
|
The tool was never called cURL, only the project. But even so, we have
more and more over time switched to just use lower case.
|
|
As otherwise the callback could be called with a NULL pointer when RTSP
data is provided.
|
|
There were bugs in the PKCS#11 engine, and fixing them triggers bugs in
OpenSSL. Just don't get involved; there's no need to be making the
engine methods the default anyway.
https://github.com/OpenSC/libp11/pull/108
https://github.com/openssl/openssl/pull/1639
Merges #1042
|
|
Reported-by: Ryan Scott
Fixes #1007
|
|
|
|
|
|
RFC7512 provides a standard method to reference certificates in PKCS#11
tokens, by means of a URI starting 'pkcs11:'.
We're working on fixing various applications so that whenever they would
have been able to use certificates from a file, users can simply insert
a PKCS#11 URI instead and expect it to work. This expectation is now a
part of the Fedora packaging guidelines, for example.
This doesn't work with cURL because of the way that the colon is used
to separate the certificate argument from the passphrase. So instead of
curl -E 'pkcs11:manufacturer=piv_II;id=%01' …
I instead need to invoke cURL with the colon escaped, like this:
curl -E 'pkcs11\:manufacturer=piv_II;id=%01' …
This is suboptimal because we want *consistency* — the URI should be
usable in place of a filename anywhere, without having strange
differences for different applications.
This patch therefore disables the processing in parse_cert_parameter()
when the string starts with 'pkcs11:'. It means you can't pass a
passphrase with an unescaped PKCS#11 URI, but there's no need to do so
because RFC7512 allows a PIN to be given as a 'pin-value' attribute in
the URI itself.
Also, if users are already using RFC7512 URIs with the colon escaped as
in the above example — even providing a passphrase for cURL to handling
instead of using a pin-value attribute, that will continue to work
because their string will start 'pkcs11\:' and won't match the check.
What *does* break with this patch is the extremely unlikely case that a
user has a file which is in the local directory and literally named
just "pkcs11", and they have a passphrase on it. If that ever happened,
the user would need to refer to it as './pkcs11:<passphrase>' instead.
|
|
After a few wasted hours hunting down the reason for slowness during a
TLS handshake that turned out to be because of TCP_NODELAY not being
set, I think we have enough motivation to toggle the default for this
option. We now enable TCP_NODELAY by default and allow applications to
switch it off.
This also makes --tcp-nodelay unnecessary, but --no-tcp-nodelay can be
used to disable it.
Thanks-to: Tim Rühsen
Bug: https://curl.haxx.se/mail/lib-2016-06/0143.html
|
|
... causing SIGSEGV while parsing URL with too many globs.
Minimal example:
$ curl $(for i in $(seq 101); do printf '{a}'; done)
Reported-by: Romain Coltel
Bug: https://bugzilla.redhat.com/1340757
|
|
Dependency added by 6cabd78
Closes #849
|
|
This broke in 7.49.0 with commit e200034425a7625
Fixes #842
|
|
Adds access to the effectively used http version to both libcurl and
curl.
Closes #799
|
|
- Move the existing scheme check from tool_operate.
In the case of --remote-header-name we want to parse Content-disposition
for a filename, but only if the scheme is http or https. A recent
adjustment 0dc4d8e was made to account for schemeless URLs however it's
not 100% accurate. To remedy that I've moved the scheme check to the
header callback, since at that point the library has already determined
the scheme.
Bug: https://github.com/curl/curl/issues/760
Reported-by: Kai Noda
|
|
It does open up a miniscule risk that one of the other protocols that
libcurl could use would send back a Content-Disposition header and then
curl would act on it even if not HTTP.
A future mitigation for this risk would be to allow the callback to ask
libcurl which protocol is being used.
Verified with test 1312
Closes #760
|
|
|
|
In commit 2e42b0a2524 (Jan 2008) we made the option "--socks" deprecated
and it has not been documented since. The more explicit socks options
(like --socks4 or --socks5) should be used.
|
|
It was mentioned as deprecated already in commit ae1912cb0d4 from
1999. It has not been documented in this millennium.
|
|
|
|
|
|
The code said "telnet-options" but no documentation ever said so. It
worked fine since the code is fine with a unique match of the first
part.
|
|
It has been deprecated and undocumented since commit ad5ead8bed7 (Dec
2003). --ftp-port is the proper long option name.
|
|
To make the aliases list reflect reality.
|
|
|
|
... moved around options so that parsing the code to find all
single-letter options easier.
|
|
The underlying libcurl option used for this feature is
CURLOPT_FTP_CREATE_MISSING_DIRS which has the ability to retry the dir
creation, but it was never set to do that by the command line tool.
Now it does.
Bug: https://curl.haxx.se/mail/archive-2016-04/0021.html
Reported-by: John Wanghui
Help-by: Leif W
|
|
|
|
|
|
|
