On second thought, I think CURLE_TLSAUTH_FAILED should be eliminated. It
was only being raised when an internal error occurred while allocating
or setting the GnuTLS SRP client credentials struct. For TLS
authentication failures, the general CURLE_SSL_CONNECT_ERROR seems
appropriate; its error string already includes "passwords" as a possible
cause. Having a separate TLS auth error code might also cause people to
think that a TLS auth failure means the wrong username or password was
entered, when it could also be a sign of a man-in-the-middle attack.
When the callback returns an error, this function must make sure to return
CURLE_ABORTED_BY_CALLBACK properly and not CURLE_OK as before to allow the
callback to properly abort the operation.
The main has not been updated from some time and is out of sync with
the code. The code is now tested by several test cases so no need for
a seperate code path.
Instead of polluting many places with #ifdefs, we create a single place
for this function, and also check return code properly so that a NULL
pointer returned won't cause problems.
The official Mozilla page at http://www.mozilla.org/projects/security/certs/
points out a new place as the "proper" place to get Mozilla's CA certs from
so this script is now updated to use that instead.
Reported by: Daniel Mentz
The official Mozilla page at
http://www.mozilla.org/projects/security/certs/ points out a new place
as the "proper" place to get Mozilla's CA certs from so this script is
now updated to use that instead.
Reported by: Daniel Mentz
The code in the toofast state needs to first recalculate the values
before it uses them again since it may have been a while since it last
did it when it reaches this point.
This will be used by file_do() and Curl_readwrite() as a unified method
of checking to see if a remote document meets the supplied
CURLOPT_TIMEVAL and CURLOPT_TIMECONDITION.
Signed-off-by: Dave Reisner <d@falconindy.com>
When this callback is called due to the destruction of the ares handle,
the connection pointer passed in as an argument may no longer pointing
to valid data and this function doesn't need to do anything with it
anyway so we make sure it doesn't.
Bug: http://curl.haxx.se/mail/lib-2011-01/0333.html
Reported by: Vsevolod Novikov
The HTTP parser allocated memory on each received Location: header
without properly freeing old data. Starting now, the code only considers
the first Location: header and will blissfully ignore subsequent ones.
Bug: http://curl.haxx.se/bug/view.cgi?id=3165129
Reported by: Martin Lemke
... and update the curl.1 and curl_easy_setopt.3 man pages such that
they do not suggest to use an OpenSSL utility if curl is not built
against OpenSSL.
Bug: https://bugzilla.redhat.com/669702
The idea that the protocol and socktype is part of name resolving in the
libc functions is nuts. We keep the name resolver functions assume
TCP/STREAM and we make sure that when we want to connect to a UDP
service we use the correct UDP/DGRAM set instead. This bug was because
the ->protocol field was not always set correctly.
This bug was only affecting ipv6-disabled non-cares non-threaded builds.
Bug: http://curl.haxx.se/bug/view.cgi?id=3154436
Reported by: "dperham"
When configure --enable-debug has been used, all files in lib/ are now
built twice and a separate static library crafted for unit-testing will
be linked. The unit tests in the tests/unit subdir will use that
library.
Since some systems don't have PATH_MAX and it isn't that clever to
assume a fixed maximum path length, the code now allocates buffer space
instead of using stack.
Reported by: Samuel Thibault
Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608521
Sending "pwd" as a QUOTE command only sent the reply to the
DEBUGFUNCTION. Now it also sends an FTP-like header to the header
callback to allow similar operations as with FTP, and apps can re-use
the same parser.
When built IPv6-enabled, we could do Curl_done() with one of the two
resolves having returned already, so when ares_cancel() is called the
resolve callback ends up doing funny things (sometimes resulting in a
segfault) since it would try to actually store the previous resolve even
though we're shutting down the resolve.
This bug was introduced in commit 8ab137b2bc so it hasn't been
included in any public release.
Bug: http://curl.haxx.se/bug/view.cgi?id=3145445
Reported by: Pedro Larroy