- Oct 22, 2005
-
-
Daniel Stenberg authored
#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.
-
- Aug 24, 2005
-
-
Daniel Stenberg authored
previously failed due to GnuTLS not allowing x509 v1 CA certs by default.
-
- Apr 22, 2005
-
-
Daniel Stenberg authored
-
- Apr 13, 2005
-
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
- Apr 09, 2005
-
-
Daniel Stenberg authored
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.)
-
Daniel Stenberg authored
bug I thought I saw before when I changed this...!
-
- Apr 07, 2005
-
-
Daniel Stenberg authored
(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.
-
Daniel Stenberg authored
internally, with code provided by sslgen.c. All SSL-layer-specific code is then written in ssluse.c (for OpenSSL) and gtls.c (for GnuTLS). As far as possible, internals should not need to know what SSL layer that is in use. Building with GnuTLS currently makes two test cases fail. TODO.gnutls contains a few known outstanding issues for the GnuTLS support. GnuTLS support is enabled with configure --with-gnutls
-