From nmav at hellug.gr Fri Jun 1 18:00:02 2001 From: nmav at hellug.gr (Nikos Mavroyanopoulos) Date: Fri Jun 1 18:00:02 2001 Subject: Libgcrypt 1.1.3 released In-Reply-To: <20010601081950.E11454@alberti.gnupg.de> References: <20010601081950.E11454@alberti.gnupg.de> Message-ID: <20010601185401.068bf2d2.nmav@hellug.gr> On Fri, 1 Jun 2001 08:19:50 +0200 Werner Koch wrote: I've just released gnutls-0.1.3 which works with the new libgcrypt. > Hi! > after quite a long time of development (actually of other stuff ;-), > a first stand-alone version of Libgcrypt has been released. This is > version 1.1.3 and should be considered as Alpha quality. We have to > use this quite high version number because Libgcrypt used to be part > of gnupg 1.1 and some other projects might have used that one and > checked the version number. From now on Libgcrypt and GnuPG > versions are not anymore bound together. > > Documentation has only partly been done - especially the PK > operations are not described :-(. Some changes made to gnupg code > are not yet in Libgcrypt; this will hapen soon but there is no > urgent need for those fixes. > > If you want to try it out: > > ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.1.3.tar.gz > (494k) > > a signature file is also available. I have tested it on GNU/Linux > systems and it should build without probmels. Please ignore a few > warnings. > > I have checked that gnutls 0.1.2 builds fine with it after removing > some macros about mpi_add etc. at the beginning of lib/gnutls_srp.c > > Have fun, > > Werner > > > -- > Werner Koch Omnis enim res, quae dando non deficit, dum habetur > g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. > Privacy Solutions -- Augustinus > > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel -- Nikos Mavroyanopoulos mailto:nmav at hellug.gr From nmav at hellug.gr Wed Jun 13 11:39:02 2001 From: nmav at hellug.gr (Nikos Mavroyanopoulos) Date: Wed Jun 13 11:39:02 2001 Subject: new developer Message-ID: <20010613123449.3b285b41.nmav@hellug.gr> I'd like to annouce a new member in gnutls developers, it's Fabio Fiorina (Fabio.Fiorina at alcatel.it), who has already written a very good ASN1/DER parser, and is now part of gnutls. -- Nikos Mavroyanopoulos mailto:nmav at hellug.gr From nmav at hellug.gr Mon Jun 18 00:44:01 2001 From: nmav at hellug.gr (Nikos Mavroyanopoulos) Date: Mon Jun 18 00:44:01 2001 Subject: RSA ciphersuites Message-ID: <20010618013931.5995ff04.nmav@hellug.gr> I've just added the rsa ciphersuites in gnutls (rsa-arcfour, rsa-3des etc.) and some support for x509/RSA certificates. All these currently apply to the server side, not client side. I've tested them against Openssl in SSL 3.0, TLS 1.0 and TLS 1.0 with SSL 2.0 client hello, and worked fine. I've also tested against netscape but failed to interoperate (I couldn't find why, but I'll check it again). -- Nikos Mavroyanopoulos mailto:nmav at hellug.gr From nmav at hellug.gr Mon Jun 18 10:12:02 2001 From: nmav at hellug.gr (Nikos Mavroyanopoulos) Date: Mon Jun 18 10:12:02 2001 Subject: errno Message-ID: <20010618110747.63cd440c.nmav@hellug.gr> While testing gnutls against other TLS implementations I got the following problem: While in the handshake procedure, the client might send a warning (if he's polite enough) and terminate immediately, if he thinks that he cannot communicate with us. However we may be in a step where we are transmiting 2 messages (eg. server hello and certificate), thus we will get a SIGPIPE and terminate. Of course this is unnacceptable for a library. I though of some solutions: 1. Document it and request to install SIG_IGN for the SIGPIPE signal before calling gnutls_handshake/gnutls_rehandshake. (that way we detect the error and behave as expected) 2. Check for pending alerts between reading two messages. This solution gives one more problem. We must check for pending alerts in a way that we'll not block. Thus we'll have to use MSG_DONTWAIT and then check errno (but what happens when multithreaded?) [this will not work if the peer closes the connection without an alert] 3. Install the signal handler while doing handshake(), and restore it when leaving (I don't really like it) Which one do you like? Any other options? -- Nikos Mavroyanopoulos mailto:nmav at hellug.gr From wk at gnupg.org Mon Jun 18 15:30:01 2001 From: wk at gnupg.org (Werner Koch) Date: Mon Jun 18 15:30:01 2001 Subject: errno In-Reply-To: <20010618110747.63cd440c.nmav@hellug.gr> (Nikos Mavroyanopoulos's message of "Mon, 18 Jun 2001 11:07:47 +0300") References: <20010618110747.63cd440c.nmav@hellug.gr> Message-ID: <87vgltyl4k.fsf@alberti.gnupg.de> || On Mon, 18 Jun 2001 11:07:47 +0300 || Nikos Mavroyanopoulos wrote: nm> 1. Document it and request to install SIG_IGN for the SIGPIPE signal before calling nm> gnutls_handshake/gnutls_rehandshake. nm> (that way we detect the error and behave as expected) That is easy and maybe you should do it for now. nm> 2. Check for pending alerts between reading two messages. Argh.... nm> [this will not work if the peer closes the connection nm> without an alert] ... this will happen. nm> 3. Install the signal handler while doing handshake(), and restore nm> it when leaving (I don't really like it) IMHO, this is the best way and the reason why POSIX has a sound specificaton of signals. Well, the OS just needs to be POSIX compliant ;-) MT apps are still a problem but this is the case anyway with MT. You might want to provide a flag to disable signal catching so that the default operation mode works inmost cases. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From danw at ximian.com Mon Jun 18 15:45:01 2001 From: danw at ximian.com (Dan Winship) Date: Mon Jun 18 15:45:01 2001 Subject: errno In-Reply-To: <20010618110747.63cd440c.nmav@hellug.gr> References: <20010618110747.63cd440c.nmav@hellug.gr> Message-ID: <992871792.9767.1.camel@twelve-monkeys.ximian.com> > 1. Document it and request to install SIG_IGN for the SIGPIPE signal before calling > gnutls_handshake/gnutls_rehandshake. libbonobo (the component-embedding library in GNOME) sets SIG_IGN for SIGPIPE in its init routine and no one has ever complained. Anyone actually using SIGPIPE intentionally deserves to lose. :-) -- Dan From nmav at hellug.gr Tue Jun 19 11:14:01 2001 From: nmav at hellug.gr (Nikos Mavroyanopoulos) Date: Tue Jun 19 11:14:01 2001 Subject: errno Message-ID: <20010619120856.4b50f99f.nmav@hellug.gr> I'll probably ignore the signal problem for now - and document that the server should ignore the SIGPIPE signal. Just tested gnutls with netscape/mozilla and works in all ssl/tls modes and with 3DES as cipher. (Arcfour encryption fails with both mcrypt and gcrypt). -- Nikos Mavroyanopoulos mailto:nmav at hellug.gr From nmav at hellug.gr Fri Jun 22 14:01:01 2001 From: nmav at hellug.gr (Nikos Mavroyanopoulos) Date: Fri Jun 22 14:01:01 2001 Subject: gnutls 0.1.4 Message-ID: <20010622145714.616d6c53.nmav@hellug.gr> I've just uploaded gnutls-0.1.4 which is just a snapshot of the work done until today. Both client/server (view the cli and serv examples) work with several limitations and they do NOT verify certificates ( which means that you shouldn't use it in any real world project - since it provides no security). I expect feedback - especially about the API! -- Nikos Mavroyanopoulos mailto:nmav at hellug.gr From jkane89 at softhome.net Sat Jun 23 17:34:01 2001 From: jkane89 at softhome.net (John Kane) Date: Sat Jun 23 17:34:01 2001 Subject: FYI: rfc2440 InterOp event Message-ID: <3B34B665.779B1459@softhome.net> >> RFC2440 Interoperability Testing The Internet Engineering Task Force (IETF) OpenPGP working group is preparing RFC2440 (OpenPGP) to be advanced from PROPOSED to DRAFT status. The OpenPGP Alliance will conduct Interoperability testing to be held in San Diego facilities in early summer of 2001. The goal of the test is to insure multiple implementations of OpenPGP successfully exchange encrypted and authenticated messages. << http://openpgp.org/news_events/events/ From wk at gnupg.org Sat Jun 23 19:32:01 2001 From: wk at gnupg.org (Werner Koch) Date: Sat Jun 23 19:32:01 2001 Subject: FYI: rfc2440 InterOp event In-Reply-To: <3B34B665.779B1459@softhome.net> (John Kane's message of "Sat, 23 Jun 2001 11:31:51 -0400") References: <3B34B665.779B1459@softhome.net> Message-ID: <8766dn14ya.fsf@alberti.gnupg.de> || On Sat, 23 Jun 2001 11:31:51 -0400 || John Kane wrote: jk> advanced from PROPOSED to DRAFT status. The OpenPGP jk> Alliance will conduct Interoperability testing to be held in jk> San Diego facilities in early summer of 2001. This is known for several month but until now nobody has a proposed schedule. If asked several people involved in this and I didn't got any answer. The WG list is also quite for some weeks. The next IETF meeting is in August and I have some doubts that the OpenPGP testing will happen prior to the IETF meeting :-( Ciao, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus