| Age | Commit message (Collapse) | Author |
|---|
|
(http://curl.haxx.se/bug/view.cgi?id=2255627) which pointed out that a
program using libcurl's multi interface to download a HTTPS page with a
libcurl built powered by OpenSSL, would easily get silly and instead hand
over SSL details as data instead of the actual HTTP headers and body. This
happened because libcurl would consider the connection handshake done too
early. This problem was introduced at September 22nd 2008 with my fix of the
bug #2107377
The correct fix is now instead done within the GnuTLS-handling code, as both
the OpenSSL and the NSS code already deal with this situation in similar
fashion. I added test case 560 in an attempt to verify this fix, but
unfortunately it didn't trigger it even before this fix!
|
|
used in strequal.c so now all test cases run fine for me again.
|
|
(http://curl.haxx.se/bug/view.cgi?id=2154627) which pointed out that libcurl
uses strcasecmp() in multiple places where it causes failures when the
Turkish locale is used. This is because 'i' and 'I' isn't the same letter so
strcasecmp() on those letters are different in Turkish than in English (or
just about all other languages). I thus introduced a totally new internal
function in libcurl (called Curl_ascii_equal) for doing case insentive
comparisons for english-(ascii?) style strings that thus will make "file"
and "FILE" match even if the Turkish locale is selected.
|
|
void *
|
|
OpenSSL, NSS and GnuTLS-built libcurls.
|
|
OpenSSL, NSS and GnuTLS-built libcurls.
|
|
Patch submitted by Kaspar Brand.
|
|
forces it to prefer SSLv3.
|
|
|
|
better control at the exact state of the connection's SSL status so that we
know exactly when it has completed the SSL negotiation or not so that there
won't be accidental re-uses of connections that are wrongly believed to be
in SSL-completed-negotiate state.
|
|
such as the CURLOPT_SSL_CTX_FUNCTION one treat that as if it was a Location:
following. The patch that introduced this feature was done for 7.11.0, but
this code and functionality has been broken since about 7.15.4 (March 2006)
with the introduction of non-blocking OpenSSL "connects".
It was a hack to begin with and since it doesn't work and hasn't worked
correctly for a long time and nobody has even noticed, I consider it a very
suitable subject for plain removal. And so it was done.
|
|
|
|
|
|
verification is requested. Previously it would even return failure if gnutls
failed to get the server cert even though no verification was asked for.
- Fix my Curl_timeleft() leftover mistake in the gnutls code
|
|
(http://curl.haxx.se/bug/view.cgi?id=1889856): When using the gnutls ssl
layer, cleaning-up and reinitializing curl ends up with https requests
failing with "ASN1 parser: Element was not found" errors. Obviously a
regression added in 7.16.3.
|
|
them all use the same (hopefully correct) logic to make it less error-prone
and easier to introduce library-wide where it should be used.
|
|
while () => while()
and some other minor re-indentings
|
|
CURLE_PEER_FAILED_VERIFICATION (standard CURL_NO_OLDIES style), and made this
return code get used by the previous SSH MD5 fingerprint check in case it
fails.
|
|
and allow reuse by multiple protocols. Several unused error codes were
removed. In all cases, macros were added to preserve source (and binary)
compatibility with the old names. These macros are subject to removal at
a future date, but probably not before 2009. An application can be
tested to see if it is using any obsolete code by compiling it with the
CURL_NO_OLDIES macro defined.
Documented some newer error codes in libcurl-error(3)
|
|
|
|
passed to it with curl_easy_setopt()! Previously it has always just refered
to the data, forcing the user to keep the data around until libcurl is done
with it. That is now history and libcurl will instead clone the given
strings and keep private copies.
|
|
of a socket after it has been closed, when the FTP-SSL data connection is taken
down.
|
|
|
|
|
|
since it then inits libgcrypt and libgcrypt is being evil and EXITS the
application if it fails to get a fine random seed. That's really not a nice
thing to do by a library.
|
|
identifying a double-free problem in the SSL-dealing layer, telling GnuTLS to
free NULL credentials on closedown after a failure and a bad #ifdef for NSS
when closing down SSL.
|
|
|
|
|
|
since they're already included through "setup.h".
|
|
different server behaviour
|
|
|
|
|
|
and CURLOPT_CONNECTTIMEOUT_MS that, as their names should hint, do the
timeouts with millisecond resolution instead. The only restriction to that
is the alarm() (sometimes) used to abort name resolves as that uses full
seconds. I fixed the FTP response timeout part of the patch.
Internally we now count and keep the timeouts in milliseconds but it also
means we multiply set timeouts with 1000. The effect of this is that no
timeout can be set to more than 2^31 milliseconds (on 32 bit systems), which
equals 24.86 days. We probably couldn't before either since the code did
*1000 on the timeout values on several places already.
|
|
curl that uses the new CURLOPT_FTP_SSL_CCC option in libcurl. If enabled, it
will make libcurl shutdown SSL/TLS after the authentication is done on a
FTP-SSL operation.
|
|
during certain conditions when GnuTLS is used.
|
|
They all now return ssize_t to Curl_write().
Unfortunately, Curl_read() is in a sorrier state but it too would benefit from
a similar cleanup.
|
|
reading the (local) CA cert file to let users easier pinpoint the actual
problem. CURLE_SSL_CACERT_BADFILE (77) is the new libcurl error code.
|
|
|
|
|
|
(http://curl.haxx.se/bug/view.cgi?id=1480821) He found and identified a
problem with how libcurl dealt with GnuTLS and a case where gnutls returned
GNUTLS_E_AGAIN indicating it would block. It would then return an unexpected
return code, making Curl_ssl_send() confuse the upper layer - causing random
28 bytes trash data to get inserted in the transfered stream.
The proper fix was to make the Curl_gtls_send() function return the proper
return codes that the callers would expect. The Curl_ossl_send() function
already did this.
|
|
|
|
client certificates! (http://curl.haxx.se/bug/view.cgi?id=1348930).
|
|
#1334338 (http://curl.haxx.se/bug/view.cgi?id=1334338). When reading an SSL
stream from a server and the server requests a "rehandshake", the current
code simply returns this as an error. I have no good way to test this, but
I've added a crude attempt of dealing with this situation slightly better -
it makes a blocking handshake if this happens. Done like this because fixing
this the "proper" way (that would handshake asynchronously) will require
quite some work and I really need a good way to test this to do such a
change.
|
|
previously failed due to GnuTLS not allowing x509 v1 CA certs by default.
|
|
|
|
|
|
|
|
Archived thread of the help-gnutls mailing list regarding this problem:
http://lists.gnu.org/archive/html/help-gnutls/2005-04/msg00000.html
(and I _am_ sorry for my confused behaviour on this problem.)
|
|
bug I thought I saw before when I changed this...!
|
|
(missing file, bad file, etc), gnutls will no longer handshake properly but it
just loops forever. Therefore, we must return error if we get an error when
setting the CA cert file name. This is not the same behaviour as with OpenSSL.
Question/report posted to the help-gnutls mailing list, April 8 2005.
|
