From smurf at smurf.noris.de Thu Dec 9 18:53:52 2004 From: smurf at smurf.noris.de (Matthias Urlichs) Date: Mon Dec 13 16:37:26 2004 Subject: [aj@andaco.de: Bug#284885: libgcrypt7: FTBFS (amd64/gcc-4.0): invalid storage class for function 'serpent_test'] Message-ID: <20041209175352.GC18775@kiste> The attached patch (actually a patch wrapped in a patch...) fixes a compilation problem with gcc-4.0. I'm not quite sure whether that's a real bug, but the result is certainly more portable, so ... -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de -------------- next part -------------- An embedded message was scrubbed... From: Andreas Jochens Subject: Bug#284885: libgcrypt7: FTBFS (amd64/gcc-4.0): invalid storage class for function 'serpent_test' Date: Thu, 09 Dec 2004 11:42:15 +0100 Size: 4238 Url: /pipermail/attachments/20041209/7480c66d/attachment.txt From wk at gnupg.org Fri Dec 10 10:40:28 2004 From: wk at gnupg.org (Werner Koch) Date: Mon Dec 13 16:37:40 2004 Subject: [aj@andaco.de: Bug#284885: libgcrypt7: FTBFS (amd64/gcc-4.0): invalid storage class for function 'serpent_test'] In-Reply-To: <20041209175352.GC18775@kiste> (Matthias Urlichs's message of "Thu, 9 Dec 2004 18:53:52 +0100") References: <20041209175352.GC18775@kiste> Message-ID: <87brd24hkj.fsf@wheatstone.g10code.de> On Thu, 9 Dec 2004 18:53:52 +0100, Matthias Urlichs said: > The attached patch (actually a patch wrapped in a patch...) fixes a > compilation problem with gcc-4.0. > I'm not quite sure whether that's a real bug, but the result is certainly > more portable, so ... Already done yesterday. Thanks, Werner From m.koster at greenhills.co.uk Mon Dec 6 12:09:31 2004 From: m.koster at greenhills.co.uk (Martijn Koster) Date: Tue Dec 14 10:29:21 2004 Subject: md2 support? Message-ID: <1102331371.20415.26.camel@yoda.home.greenhills.co.uk> Hi all, I ran into various certificate chains that gnutls cannot verify because they use a Verisign CA certificate with an md2 hash, which is not supported in gnutls, because there is no md2 support in libgcrypt. This was previously reported by Luca Centamore, archived in http://lists.gnupg.org/pipermail/gpa-dev/2003-October.txt. Werner Koch explained md2 support was removed because rfc1319 lists it as licensed for PEM only, and because the algorithm is ancient and useless. I recalled hearing that RSA had later extended that license to "any purpose", and after some searching I found this documented at http://www.ietf.org/ietf/IPR/RSA-MD-all. Does this address Werner's licensing concerns? Now I know the use of MD2 is no longer recommended because of weaknesses. But it seems wrong to restrict the ability to communicate with SSL servers using those certificates solely because we know the checksum algorithm is weak. For comparison, Mozilla's NSS does support these certificates. Personally I would obtain certificates that wouldn't have these issues, but obviously these certificates issued to third parties are not something I can control. I would therefore ask you to please reconsider adding md2-support back. Regards, -- Martijn From rafael.espindola at gmail.com Tue Dec 7 13:45:55 2004 From: rafael.espindola at gmail.com (Rafael =?iso-8859-1?q?=C1vila_de_Esp=EDndola?=) Date: Tue Dec 14 10:29:23 2004 Subject: Illegal instruction on power4+ Message-ID: <200412071045.56275.rafael.espindola@gmail.com> I am trying to use libgcrypt in a p615 but it is trying to use powerpc assembly code which causes it to fail with a "Illegal instruction". In /proc/cpu there is: -------------------------------------- processor : 0 cpu : POWER4+ (gq) clock : 1452.000000MHz revision : 2.1 ---------------------------------------- and the target is powerpc64-unknown-linux-gnu. I don't know why the powerpc code is not working in this processor, but moving the "powerpc64*-*-* " before "powerpc*-*-linux*" in config,links makes libgcrypt use generic c implementations and solves the problem. In fact, it is useless to have "powerpc64*-*-* " after "powerpc*-*-linux*" since every powerpc64 linux target would match the first. Rafael From stamer at flower.theory.informatik.uni-kassel.de Fri Dec 10 09:51:24 2004 From: stamer at flower.theory.informatik.uni-kassel.de (Heiko Stamer) Date: Tue Dec 14 10:29:26 2004 Subject: Undefined symbols libgcrypt-1.2.0/tests/ac.c (Solaris 2.7) Message-ID: <20041210085124.GA13850@flower.theory.informatik.uni-kassel.de> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : /pipermail/attachments/20041210/b18948b9/attachment-0001.bin From wk at gnupg.org Thu Dec 16 17:13:46 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 16 17:14:54 2004 Subject: md2 support? In-Reply-To: <1102331371.20415.26.camel@yoda.home.greenhills.co.uk> (Martijn Koster's message of "Mon, 06 Dec 2004 11:09:31 +0000") References: <1102331371.20415.26.camel@yoda.home.greenhills.co.uk> Message-ID: <87mzwei5l1.fsf@wheatstone.g10code.de> On Mon, 06 Dec 2004 11:09:31 +0000, Martijn Koster said: > Werner Koch explained md2 support was removed because rfc1319 lists it > as licensed for PEM only, and because the algorithm is ancient and > useless. I still believe in that. > I recalled hearing that RSA had later extended that license to "any > purpose", and after some searching I found this documented at > http://www.ietf.org/ietf/IPR/RSA-MD-all. Does this address Werner's > licensing concerns? Okay, that is fine. > I would therefore ask you to please reconsider adding md2-support back. Well, we can do that but first of all we need an implementation. There has never been MD2 support in Libgcrypt. An implementation most be done from scratch or real public domain code. The author needs to sign a disclaimer or assignment to the FSF. Would you like to work on it. In general it is pretty straightforward to do a simple implementation from the specs. Take rmd160.c or md5.c as a template. Werner From nmav at gnutls.org Thu Dec 16 17:41:12 2004 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu Dec 16 17:38:54 2004 Subject: md2 support? In-Reply-To: <87mzwei5l1.fsf@wheatstone.g10code.de> References: <1102331371.20415.26.camel@yoda.home.greenhills.co.uk> <87mzwei5l1.fsf@wheatstone.g10code.de> Message-ID: <200412161741.12340.nmav@gnutls.org> On Thursday 16 December 2004 17:13, Werner Koch wrote: > > I recalled hearing that RSA had later extended that license to "any > > purpose", and after some searching I found this documented at > > http://www.ietf.org/ietf/IPR/RSA-MD-all. Does this address Werner's > > licensing concerns? > Okay, that is fine. > > I would therefore ask you to please reconsider adding md2-support back. > Well, we can do that but first of all we need an implementation. > There has never been MD2 support in Libgcrypt. An implementation most > be done from scratch or real public domain code. The author needs to > sign a disclaimer or assignment to the FSF. Nettle already includes an implementation of md2 written by Niels. > Werner -- Nikos Mavrogiannopoulos From wk at gnupg.org Thu Dec 16 21:14:22 2004 From: wk at gnupg.org (Werner Koch) Date: Thu Dec 16 21:14:38 2004 Subject: md2 support? In-Reply-To: <200412161741.12340.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 16 Dec 2004 17:41:12 +0100") References: <1102331371.20415.26.camel@yoda.home.greenhills.co.uk> <87mzwei5l1.fsf@wheatstone.g10code.de> <200412161741.12340.nmav@gnutls.org> Message-ID: <877jnif1b5.fsf@wheatstone.g10code.de> On Thu, 16 Dec 2004 17:41:12 +0100, Nikos Mavrogiannopoulos said: > Nettle already includes an implementation of md2 written by Niels. If he would only assign copyright to the FSF ... Werner From rkit at mur.at Thu Dec 16 22:23:49 2004 From: rkit at mur.at (Rupert Kittinger) Date: Thu Dec 16 22:20:26 2004 Subject: memory leak in rsa.c Message-ID: <41C1FCE5.508@mur.at> Hello everybody, I think I found a memory leak in 1.2.0 in file rsa.c. (with the generous support of valgrind...) Patch is attached. Rupert -- Rupert Kittinger -------------- next part -------------- diff -upr libgcrypt-1.2.0/cipher/rsa.c libgcrypt-1.2.0-patched/cipher/rsa.c --- libgcrypt-1.2.0/cipher/rsa.c 2003-12-11 16:02:43.000000000 +0100 +++ libgcrypt-1.2.0-patched/cipher/rsa.c 2004-12-16 18:13:58.763112002 +0100 @@ -547,6 +547,7 @@ _gcry_rsa_decrypt (int algo, gcry_mpi_t gcry_mpi_release (y); y = rsa_unblind (a, ri, sk.n); + gcry_mpi_release (a); } if (! (flags & PUBKEY_FLAG_NO_BLINDING)) From wk at gnupg.org Fri Dec 17 10:03:59 2004 From: wk at gnupg.org (Werner Koch) Date: Fri Dec 17 10:04:41 2004 Subject: memory leak in rsa.c In-Reply-To: <41C1FCE5.508@mur.at> (Rupert Kittinger's message of "Thu, 16 Dec 2004 22:23:49 +0100") References: <41C1FCE5.508@mur.at> Message-ID: <87hdmlcn40.fsf@wheatstone.g10code.de> On Thu, 16 Dec 2004 22:23:49 +0100, Rupert Kittinger said: > I think I found a memory leak in 1.2.0 in file rsa.c. (with the > generous support of valgrind...) Thanks. It has been fixed in the CVS for quite some time. I see that we should do a new release RSN. Werner From rkit at mur.at Fri Dec 17 12:32:34 2004 From: rkit at mur.at (Rupert Kittinger) Date: Fri Dec 17 12:29:20 2004 Subject: memory leak in rsa.c In-Reply-To: <87hdmlcn40.fsf@wheatstone.g10code.de> References: <41C1FCE5.508@mur.at> <87hdmlcn40.fsf@wheatstone.g10code.de> Message-ID: > On Thu, 16 Dec 2004 22:23:49 +0100, Rupert Kittinger said: > > > I think I found a memory leak in 1.2.0 in file rsa.c. (with the > > generous support of valgrind...) > > Thanks. It has been fixed in the CVS for quite some time. I see that > we should do a new release RSN. > > Werner > > I must have overlooked that. I scanned the archive of the developer mailing list, and just found a different memory leak mentioned (in pubkey.c) By the way, is there any bugtracking system available for glibcrypt? Rupert From mo at g10code.com Sun Dec 19 22:42:41 2004 From: mo at g10code.com (Moritz Schulte) Date: Mon Dec 20 11:02:54 2004 Subject: Undefined symbols libgcrypt-1.2.0/tests/ac.c (Solaris 2.7) In-Reply-To: <20041210085124.GA13850@flower.theory.informatik.uni-kassel.de> References: <20041210085124.GA13850@flower.theory.informatik.uni-kassel.de> Message-ID: <20041219214241.GB17905@sarkutty> On Fri, Dec 10, 2004 at 09:51:24AM +0100, Heiko Stamer wrote: Hello, > the following error appears during the build of libgcrypt-1.2.0 on > Solaris (with non-gnu linker) This is really strange. Could you please send a tarball containing your Libgcrypt build tree to me? Thanks, Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 193 bytes Desc: not available Url : /pipermail/attachments/20041219/020dde1a/attachment.bin From jandre at cmtek.com Mon Dec 20 21:52:38 2004 From: jandre at cmtek.com (Jean ANDRE) Date: Mon Dec 20 22:27:50 2004 Subject: Windows only - how to generate make file Message-ID: <41C73B96.4020007@cmtek.com> Hello guys, I've only a windows station. Could you please tell me how to generate the makefile for windows because I've only a windows machine. I saw that you have a w32-dll folder but there is no makefile for Windows. I presently working under Visual C++, version 7.1, under Windows 2000. Or do you have some binaries version, ready to use ? Thanks in advance ! Jean A. - Canada From wk at gnupg.org Tue Dec 21 08:56:38 2004 From: wk at gnupg.org (Werner Koch) Date: Tue Dec 21 08:59:44 2004 Subject: Windows only - how to generate make file In-Reply-To: <41C73B96.4020007@cmtek.com> (Jean ANDRE's message of "Tue, 21 Dec 2004 01:52:38 +0500") References: <41C73B96.4020007@cmtek.com> Message-ID: <87acs8uls9.fsf@wheatstone.g10code.de> On Tue, 21 Dec 2004 01:52:38 +0500, Jean ANDRE said: > I've only a windows station. Could you please tell me how to generate > the makefile for windows because I've only a windows machine. I saw > that you have a w32-dll folder but there is no makefile for Windows. That one is outdated; we have not yet agreend on a final definition for the W32 ABI. As of now you may only use a cross compiler: The latest CVS LIBGCRYPT-1-2-BRANCH simply needs: ./autogen.sh --build-w32 && make this should also work on a mingw/MSYS installation (www.mingw.org). Werner