From kurt at roeckx.be Sat Jul 3 11:48:13 2010 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 3 Jul 2010 11:48:13 +0200 Subject: Blackfin and version scripts In-Reply-To: <87pqzjqu7g.fsf@vigenere.g10code.de> References: <87pqzjqu7g.fsf@vigenere.g10code.de> Message-ID: <20100703094813.GA18698@roeckx.be> On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote: > Hi! > > GCRYPT_1.2 { > global: > gcry_check_version; gcry_control; > [...] > > Blackfin seems to be the only platform which has version script support > and prefixes symbols with underscores. That does not work of course. blackfins is one of the arches that defined underscores in the ABI. But I don't think an application writer should care about that, and that this is a bug in binutils. Kurt From vapier at gentoo.org Mon Jul 5 09:43:21 2010 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 5 Jul 2010 03:43:21 -0400 Subject: Blackfin and version scripts In-Reply-To: <20100703094813.GA18698@roeckx.be> References: <87pqzjqu7g.fsf@vigenere.g10code.de> <20100703094813.GA18698@roeckx.be> Message-ID: <201007050343.22895.vapier@gentoo.org> On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote: > On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote: > > Hi! > > > > GCRYPT_1.2 { > > > > global: > > gcry_check_version; gcry_control; > > > > [...] > > > > Blackfin seems to be the only platform which has version script support > > and prefixes symbols with underscores. That does not work of course. > > blackfins is one of the arches that defined underscores in the > ABI. But I don't think an application writer should care about > that, and that this is a bug in binutils. no, it isnt. please read the whole thread and the linker documentation. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From kurt at roeckx.be Mon Jul 5 18:50:09 2010 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 5 Jul 2010 18:50:09 +0200 Subject: Blackfin and version scripts In-Reply-To: <201007050343.22895.vapier@gentoo.org> References: <87pqzjqu7g.fsf@vigenere.g10code.de> <20100703094813.GA18698@roeckx.be> <201007050343.22895.vapier@gentoo.org> Message-ID: <20100705165009.GA18187@roeckx.be> On Mon, Jul 05, 2010 at 03:43:21AM -0400, Mike Frysinger wrote: > On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote: > > On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote: > > > Hi! > > > > > > GCRYPT_1.2 { > > > > > > global: > > > gcry_check_version; gcry_control; > > > > > > [...] > > > > > > Blackfin seems to be the only platform which has version script support > > > and prefixes symbols with underscores. That does not work of course. > > > > blackfins is one of the arches that defined underscores in the > > ABI. But I don't think an application writer should care about > > that, and that this is a bug in binutils. > > no, it isnt. please read the whole thread and the linker documentation. I'm not sure which part of the thread you think I missed that said anything about it. Most of it is actually about complelty unrelated issues that have nothing to do with bfin. The only mail that seems to be about it is Ralf's mail about the mangling. But I'm not convinced that libtool should do any mangle/demangle thing. Atleast the gnu linker will already do the proper thing for you, but some others might not. If you think I missed something, please point me to the actual mail or documentation. Kurt From vapier.adi at gmail.com Mon Jul 5 22:08:47 2010 From: vapier.adi at gmail.com (Mike Frysinger) Date: Mon, 5 Jul 2010 16:08:47 -0400 Subject: Blackfin and version scripts In-Reply-To: <20100705165009.GA18187@roeckx.be> References: <87pqzjqu7g.fsf@vigenere.g10code.de> <20100703094813.GA18698@roeckx.be> <201007050343.22895.vapier@gentoo.org> <20100705165009.GA18187@roeckx.be> Message-ID: On Mon, Jul 5, 2010 at 12:50, Kurt Roeckx wrote: > On Mon, Jul 05, 2010 at 03:43:21AM -0400, Mike Frysinger wrote: >> On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote: >> > On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote: >> > > Hi! >> > > >> > > ? GCRYPT_1.2 { >> > > >> > > ? ? global: >> > > ? ? ? gcry_check_version; gcry_control; >> > > >> > > ? [...] >> > > >> > > Blackfin seems to be the only platform which has version script support >> > > and prefixes symbols with underscores. ?That does not work of course. >> > >> > blackfins is one of the arches that defined underscores in the >> > ABI. ?But I don't think an application writer should care about >> > that, and that this is a bug in binutils. >> >> no, it isnt. ?please read the whole thread and the linker documentation. > > I'm not sure which part of the thread you think I missed that said > anything about it. ?Most of it is actually about complelty > unrelated issues that have nothing to do with bfin. > > The only mail that seems to be about it is Ralf's mail about the > mangling. ?But I'm not convinced that libtool should do any > mangle/demangle thing. ?Atleast the gnu linker will already do the > proper thing for you, but some others might not. > > If you think I missed something, please point me to the actual > mail or documentation. you stated "it is a bug in binutils". that is simply wrong. the linker script deals in *linker visible* symbols while C code deals in *C visible*. it has always been this way and as you indirectly stated, this is not Blackfin specific. -mike From kurt at roeckx.be Tue Jul 6 18:34:13 2010 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 6 Jul 2010 18:34:13 +0200 Subject: Blackfin and version scripts In-Reply-To: References: <87pqzjqu7g.fsf@vigenere.g10code.de> <20100703094813.GA18698@roeckx.be> <201007050343.22895.vapier@gentoo.org> <20100705165009.GA18187@roeckx.be> Message-ID: <20100706163413.GA1420@roeckx.be> On Mon, Jul 05, 2010 at 04:08:47PM -0400, Mike Frysinger wrote: > On Mon, Jul 5, 2010 at 12:50, Kurt Roeckx wrote: > > On Mon, Jul 05, 2010 at 03:43:21AM -0400, Mike Frysinger wrote: > >> On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote: > >> > On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote: > >> > > Hi! > >> > > > >> > > ? GCRYPT_1.2 { > >> > > > >> > > ? ? global: > >> > > ? ? ? gcry_check_version; gcry_control; > >> > > > >> > > ? [...] > >> > > > >> > > Blackfin seems to be the only platform which has version script support > >> > > and prefixes symbols with underscores. ?That does not work of course. > >> > > >> > blackfins is one of the arches that defined underscores in the > >> > ABI. ?But I don't think an application writer should care about > >> > that, and that this is a bug in binutils. > >> > >> no, it isnt. ?please read the whole thread and the linker documentation. > > > > I'm not sure which part of the thread you think I missed that said > > anything about it. ?Most of it is actually about complelty > > unrelated issues that have nothing to do with bfin. > > > > The only mail that seems to be about it is Ralf's mail about the > > mangling. ?But I'm not convinced that libtool should do any > > mangle/demangle thing. ?Atleast the gnu linker will already do the > > proper thing for you, but some others might not. > > > > If you think I missed something, please point me to the actual > > mail or documentation. > > you stated "it is a bug in binutils". that is simply wrong. the > linker script deals in *linker visible* symbols while C code deals in > *C visible*. it has always been this way and as you indirectly > stated, this is not Blackfin specific. We're talking about a version script, not a linker script. But my point is that a version script is nothing arch specific, unlike a linker script. Version scripts even support saying in which language the symbol is, so that it can properly mangle it for you. Adding the symbol inside an 'extern "C"' also doesn't have any effect. If you use a debugger, you also want to use "break main", and that actually works, even if the symbol is really called _main in the file. You don't want to do "break _main" just because the platform's ABI says that's the way symbols are named. Kurt From vapier at gentoo.org Tue Jul 6 19:08:26 2010 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 6 Jul 2010 13:08:26 -0400 Subject: Blackfin and version scripts In-Reply-To: <20100706163413.GA1420@roeckx.be> References: <87pqzjqu7g.fsf@vigenere.g10code.de> <20100706163413.GA1420@roeckx.be> Message-ID: <201007061308.28256.vapier@gentoo.org> On Tuesday, July 06, 2010 12:34:13 Kurt Roeckx wrote: > On Mon, Jul 05, 2010 at 04:08:47PM -0400, Mike Frysinger wrote: > > On Mon, Jul 5, 2010 at 12:50, Kurt Roeckx wrote: > > > On Mon, Jul 05, 2010 at 03:43:21AM -0400, Mike Frysinger wrote: > > >> On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote: > > >> > On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote: > > >> > > Hi! > > >> > > > > >> > > GCRYPT_1.2 { > > >> > > > > >> > > global: > > >> > > gcry_check_version; gcry_control; > > >> > > > > >> > > [...] > > >> > > > > >> > > Blackfin seems to be the only platform which has version script > > >> > > support and prefixes symbols with underscores. That does not > > >> > > work of course. > > >> > > > >> > blackfins is one of the arches that defined underscores in the > > >> > ABI. But I don't think an application writer should care about > > >> > that, and that this is a bug in binutils. > > >> > > >> no, it isnt. please read the whole thread and the linker > > >> documentation. > > > > > > I'm not sure which part of the thread you think I missed that said > > > anything about it. Most of it is actually about complelty > > > unrelated issues that have nothing to do with bfin. > > > > > > The only mail that seems to be about it is Ralf's mail about the > > > mangling. But I'm not convinced that libtool should do any > > > mangle/demangle thing. Atleast the gnu linker will already do the > > > proper thing for you, but some others might not. > > > > > > If you think I missed something, please point me to the actual > > > mail or documentation. > > > > you stated "it is a bug in binutils". that is simply wrong. the > > linker script deals in *linker visible* symbols while C code deals in > > *C visible*. it has always been this way and as you indirectly > > stated, this is not Blackfin specific. > > We're talking about a version script, not a linker script. typo; i meant version script > But my point is that a version script is nothing arch specific, > unlike a linker script. Version scripts even support saying in > which language the symbol is, so that it can properly mangle it > for you. Adding the symbol inside an 'extern "C"' also doesn't > have any effect. with no lang spec, it is arch specific because it is dealing in linker visible symbols. you are correct that 'extern "C"' should work though. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From wk at g10code.com Tue Jul 13 18:06:27 2010 From: wk at g10code.com (Werner Koch) Date: Tue, 13 Jul 2010 18:06:27 +0200 Subject: Libgcrypt 1.4.6 released Message-ID: <87iq4je58c.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.4.6. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.4.6: * New variants of the TIGER algorithm. * New cipher algorithm mode for AES-WRAP. Source code is hosted at the GnuPG FTP server and its mirrors as listed at . On the primary server the source file and its digital signature is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.6.tar.bz2 (1125k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.6.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.6.tar.gz (1391k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.6.tar.gz.sig Alternativley you may upgrade version 1.4.5 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.5-1.4.6.diff.bz2 (16k) The SHA-1 checksums are: 445b9e158aaf91e24eae3d1040c6213e9d9f5ba6 libgcrypt-1.4.6.tar.bz2 dbe3fee0a9eea8128a1e47c973e0f432a62bfaa2 libgcrypt-1.4.6.tar.gz 9361c5ee7861548a4822e58baba95c81ec878384 libgcrypt-1.4.5-1.4.6.diff.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. Note that this version is from the stable branch; the current development version is available at . Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [2], order extensions or support or more general by donating money to the Free Software movement (e.g. ). Commercial support contracts for Libgcrypt are available [3], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company, is currently funding Libgcrypt development. We are always looking for interesting development projects. Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See . [2] Note that copyright assignments to the FSF are required. [3] See the service directory at . -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: From smueller at chronox.de Fri Jul 16 16:25:08 2010 From: smueller at chronox.de (Stephan Mueller) Date: Fri, 16 Jul 2010 16:25:08 +0200 Subject: [PATCH] MD2 for libgcrypt Message-ID: <1279290308.1880.65.camel@tauon> Hi, please see attached the patch adding MD2 to libgcrypt. The implementation is copied from NSS. As this implementation is covered by the LGPL, it should be consistent with libgcrypt. The code works, the test case passes (and I even verified that negative tests fail). Furthermore, I am able to import the infamous Verisign Class 1 certificate using MD2 into the key store with gpgsm. Please verify the code attached and let me know. There is one issue I need help with: I have no real idea about the size I should add to burn_stack(). The code base is libgcrypt 1.4.4 as found on Ubuntu Lucid. Thanks Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: md2_cipher.patch Type: text/x-patch Size: 9121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: md2_confighin.patch Type: text/x-patch Size: 369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: md2_configureac.patch Type: text/x-patch Size: 807 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: md2_src.patch Type: text/x-patch Size: 513 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: md2_tests.patch Type: text/x-patch Size: 592 bytes Desc: not available URL: From smueller at chronox.de Fri Jul 16 15:25:36 2010 From: smueller at chronox.de (Stephan Mueller) Date: Fri, 16 Jul 2010 15:25:36 +0200 Subject: [PATCH] MD2 for libgcrypt Message-ID: <1279286736.1880.62.camel@tauon> Hi, please see attached the patch adding MD2 to libgcrypt. The implementation is copied from NSS. As this implementation is covered by the LGPL, it should be consistent with libgcrypt. The code works, the test case passes (and I even verified that negative tests fail). Furthermore, I am able to import the infamous Verisign Class 1 certificate using MD2 into the key store with gpgsm. Please verify the code attached and let me know. The code base is libgcrypt 1.4.4 as found on Ubuntu Lucid. Thanks Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: md2_cipher.patch Type: text/x-patch Size: 9121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: md2_confighin.patch Type: text/x-patch Size: 369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: md2_configureac.patch Type: text/x-patch Size: 807 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: md2_src.patch Type: text/x-patch Size: 513 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: md2_tests.patch Type: text/x-patch Size: 592 bytes Desc: not available URL: From ametzler at downhill.at.eu.org Sat Jul 17 15:28:06 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 17 Jul 2010 15:28:06 +0200 Subject: Build failure against binutils-gold Message-ID: <6on8h7-jik.ln1@argenau.downhill.at.eu.org> Hello, libgcrypt tests fail to build with binutils-gold. Some tests directly use gpg-error functions, but are not linked against libgpg-error. I think the simple fix of linking all tests (even the ones not using gpg-error) against libgpg-error is acceptable. - Since the test binaries are not installed, a little bit of extra linkage will not hurt. ---------------------- --- libgcrypt11-1.4.6.orig/tests/Makefile.am +++ libgcrypt11-1.4.6/tests/Makefile.am @@ -36,7 +36,8 @@ TESTS += benchmark AM_CPPFLAGS = -I../src -I$(top_srcdir)/src AM_CFLAGS = $(GPG_ERROR_CFLAGS) -LDADD = ../src/libgcrypt.la $(DL_LIBS) +# some test programs use gpg-error functions directly, link against it. +LDADD = ../src/libgcrypt.la $(DL_LIBS) $(GPG_ERROR_LIBS) EXTRA_PROGRAMS = testapi pkbench noinst_PROGRAMS = $(TESTS) fipsdrv ---------------------- cu andreas http://bugs.debian.org/555179 -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From smueller at chronox.de Fri Jul 16 21:29:35 2010 From: smueller at chronox.de (Stephan Mueller) Date: Fri, 16 Jul 2010 21:29:35 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <1279290308.1880.65.camel@tauon> References: <1279290308.1880.65.camel@tauon> Message-ID: <1279308575.1880.81.camel@tauon> Am Freitag, den 16.07.2010, 16:25 +0200 schrieb Stephan Mueller: > Hi, Hi again, as the issue with the Verisign CA certificates would be solved with this patch and considering that the Verisign CAs are used pervasively, may I ask whether it is possible to add the Verisign CAs to com-certs.pem? However, I have one question: as far as I understand, the list in com-certs.pem are used as trusted certificates, not needing to reference them in trustlist.txt. However, the Verisign CA certs all need the "relax" flag as otherwise the CA cert is not accepted by gpgsm. How can that "relax" flag be assumed for the Verisign CA certs, if they are in com-certs.pem? Thanks Stephan > > please see attached the patch adding MD2 to libgcrypt. The > implementation is copied from NSS. As this implementation is covered by > the LGPL, it should be consistent with libgcrypt. > > The code works, the test case passes (and I even verified that negative > tests fail). > > Furthermore, I am able to import the infamous Verisign Class 1 > certificate using MD2 into the key store with gpgsm. > > Please verify the code attached and let me know. > > There is one issue I need help with: I have no real idea about the size I should add to burn_stack(). > > The code base is libgcrypt 1.4.4 as found on Ubuntu Lucid. > > Thanks > Stephan > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel From smueller at chronox.de Mon Jul 19 11:57:38 2010 From: smueller at chronox.de (Stephan Mueller) Date: Mon, 19 Jul 2010 11:57:38 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <1279286736.1880.62.camel@tauon> References: <1279286736.1880.62.camel@tauon> Message-ID: <1279533458.3042.6.camel@tauon> Am Freitag, den 16.07.2010, 15:25 +0200 schrieb Stephan Mueller: > Hi, Hi, please see attached patch to enable md2 with libksba. Ciao Stephan > > please see attached the patch adding MD2 to libgcrypt. The > implementation is copied from NSS. As this implementation is covered by > the LGPL, it should be consistent with libgcrypt. > > The code works, the test case passes (and I even verified that negative > tests fail). > > Furthermore, I am able to import the infamous Verisign Class 1 > certificate using MD2 into the key store with gpgsm. > > Please verify the code attached and let me know. > > The code base is libgcrypt 1.4.4 as found on Ubuntu Lucid. > > Thanks > Stephan > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: md2_ksba_keyinfo.diff Type: text/x-patch Size: 532 bytes Desc: not available URL: From sm at chronox.de Mon Jul 19 11:40:12 2010 From: sm at chronox.de (Stephan Mueller) Date: Mon, 19 Jul 2010 11:40:12 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <1279286736.1880.62.camel@tauon> References: <1279286736.1880.62.camel@tauon> Message-ID: <1279532412.3042.0.camel@tauon> Am Freitag, den 16.07.2010, 15:25 +0200 schrieb Stephan Mueller: > Hi, Hi, please see attached patch to enable md2 with libksba. Ciao Stephan > > please see attached the patch adding MD2 to libgcrypt. The > implementation is copied from NSS. As this implementation is covered by > the LGPL, it should be consistent with libgcrypt. > > The code works, the test case passes (and I even verified that negative > tests fail). > > Furthermore, I am able to import the infamous Verisign Class 1 > certificate using MD2 into the key store with gpgsm. > > Please verify the code attached and let me know. > > The code base is libgcrypt 1.4.4 as found on Ubuntu Lucid. > > Thanks > Stephan > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: md2_ksba_keyinfo.diff Type: text/x-patch Size: 532 bytes Desc: not available URL: From wk at gnupg.org Mon Jul 19 15:52:07 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Jul 2010 15:52:07 +0200 Subject: Build failure against binutils-gold In-Reply-To: <6on8h7-jik.ln1@argenau.downhill.at.eu.org> (Andreas Metzler's message of "Sat, 17 Jul 2010 15:28:06 +0200") References: <6on8h7-jik.ln1@argenau.downhill.at.eu.org> Message-ID: <878w57a8ag.fsf@vigenere.g10code.de> On Sat, 17 Jul 2010 15:28, ametzler at downhill.at.eu.org said: > libgcrypt tests fail to build with binutils-gold. Some tests directly It is sad that libgcrypt builds on a huge variety of platforms using all kinds of toolchains but the only linker whichs yields problem is the one supposed to replace the standard binutils based GNU ld :-( It would be much better to fix that shiny golden linker than to fix makefiles around for a decade and more. All the trouble of C double plus now hitting those who try avoid it. > -LDADD = ../src/libgcrypt.la $(DL_LIBS) > +# some test programs use gpg-error functions directly, link against it. > +LDADD = ../src/libgcrypt.la $(DL_LIBS) $(GPG_ERROR_LIBS) Okay, will do so for. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From n3npq at mac.com Mon Jul 19 15:57:31 2010 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 19 Jul 2010 09:57:31 -0400 Subject: Build failure against binutils-gold In-Reply-To: <878w57a8ag.fsf@vigenere.g10code.de> References: <6on8h7-jik.ln1@argenau.downhill.at.eu.org> <878w57a8ag.fsf@vigenere.g10code.de> Message-ID: On Jul 19, 2010, at 9:52 AM, Werner Koch wrote: > On Sat, 17 Jul 2010 15:28, ametzler at downhill.at.eu.org said: > >> libgcrypt tests fail to build with binutils-gold. Some tests directly > > It is sad that libgcrypt builds on a huge variety of platforms using all > kinds of toolchains but the only linker whichs yields problem is the one > supposed to replace the standard binutils based GNU ld :-( > > It would be much better to fix that shiny golden linker than to fix > makefiles around for a decade and more. All the trouble of C double > plus now hitting those who try avoid it. > Amen, brother. 73 de Jeff From dkg at fifthhorseman.net Mon Jul 19 19:38:30 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 19 Jul 2010 13:38:30 -0400 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <1279308575.1880.81.camel@tauon> References: <1279290308.1880.65.camel@tauon> <1279308575.1880.81.camel@tauon> Message-ID: <4C448D96.7090209@fifthhorseman.net> On 07/16/2010 03:29 PM, Stephan Mueller wrote: > as the issue with the Verisign CA certificates would be solved with this > patch and considering that the Verisign CAs are used pervasively, may I > ask whether it is possible to add the Verisign CAs to com-certs.pem? are you talking about certificates for the verisign root(s)? or are you talking about intermediate verisign CA certificate? If it's the former, the digest used shouldn't matter -- what matters is the public key material and any internal constraints set (e.g. expiration dates). Validating a self-signature (esp. one with a known-weak digest) for a trusted root CA certificate is a basically meaningless operation. > However, I have one question: as far as I understand, the list in > com-certs.pem are used as trusted certificates, not needing to reference > them in trustlist.txt. However, the Verisign CA certs all need the > "relax" flag as otherwise the CA cert is not accepted by gpgsm. If there are specific warnings that come up in this use case with Verisign CA certs, we should address those warnings as specific bugs themselves unrelated to the MD2 implementation (or lack thereof). I'm not arguing for discarding the offered MD2 patch (this functionality would be good to have available), but i don't think it's relevant in the scenario you're describing (at least as i understand it). Are there specific bugs related to the use of verisign root CA certs? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From smueller at chronox.de Mon Jul 19 20:15:37 2010 From: smueller at chronox.de (Stephan Mueller) Date: Mon, 19 Jul 2010 20:15:37 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <4C448D96.7090209@fifthhorseman.net> References: <1279290308.1880.65.camel@tauon> <1279308575.1880.81.camel@tauon> <4C448D96.7090209@fifthhorseman.net> Message-ID: <201007192015.37663.smueller@chronox.de> Am Montag 19 Juli 2010, um 19:38:30 schrieb Daniel Kahn Gillmor: > On 07/16/2010 03:29 PM, Stephan Mueller wrote: > > as the issue with the Verisign CA certificates would be solved with this > > patch and considering that the Verisign CAs are used pervasively, may I > > ask whether it is possible to add the Verisign CAs to com-certs.pem? > > are you talking about certificates for the verisign root(s)? or are you > talking about intermediate verisign CA certificate? > > If it's the former, the digest used shouldn't matter -- what matters is > the public key material and any internal constraints set (e.g. > expiration dates). Validating a self-signature (esp. one with a > known-weak digest) for a trusted root CA certificate is a basically > meaningless operation. Both, there is the root cert (and I concur with your assessment), but there are also intermediate certs with MD2 too. The problem with any of these MD2 certs is that you cannot do a gpgsm --import because gpgsm simply rejects them due to the MD2 hash. And during the import, the hash is also validated. So, unless you want to break gpgsm (a bad thing to do), you have no choice but to implement MD2 to allow these certs to be imported. > > > However, I have one question: as far as I understand, the list in > > com-certs.pem are used as trusted certificates, not needing to reference > > them in trustlist.txt. However, the Verisign CA certs all need the > > "relax" flag as otherwise the CA cert is not accepted by gpgsm. > > If there are specific warnings that come up in this use case with > Verisign CA certs, we should address those warnings as specific bugs > themselves unrelated to the MD2 implementation (or lack thereof). The issue is that the CA certs and intermediate certs are simply broken, look for yourself: $ gpgsm --dump-keys 77AF556F /home/sm/.gnupg/pubring.kbx --------------------------- ID: 0x77AF556F S/N: 00CDBA7F56F0DFE4BC54FE22ACB372AA55 Issuer: OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US sha1_fpr: 90:AE:A2:69:85:FF:14:80:4C:43:49:52:EC:E9:60:84:77:AF:55:6F md5_fpr: 97:60:E8:57:5F:D3:50:47:E5:43:0C:94:36:8A:B0:62 certid: 3D1AC4939E5BD1DA69D13DE8F33E9E28F9989FD6.00CDBA7F56F0DFE4BC54FE22ACB372AA55 keygrip: 5728C8A3DE5C45305F78A6B108CBCDEB6A3D2B29 notBefore: 1996-01-29 00:00:00 notAfter: 2028-08-01 23:59:59 hashAlgo: 1.2.840.113549.1.1.2 (md2WithRSAEncryption) keyType: 1024 bit RSA subjKeyId: [none] authKeyId: [none] keyUsage: [none] extKeyUsage: [none] policies: [none] chainLength: [none] crlDP: [none] authInfo: [none] subjInfo: [none] You see, there is no key usage or such. > > I'm not arguing for discarding the offered MD2 patch (this functionality > would be good to have available), but i don't think it's relevant in the > scenario you're describing (at least as i understand it). Well, Werner already told me that he is not integrating the patches. However, as the patches only enable the signature verification of an already existing signature, I cannot fully understand the decision. > > Are there specific bugs related to the use of verisign root CA certs? Not in gpgsm, only with the certs themselves. Ciao Stephan > > Regards, > > --dkg From dkg at fifthhorseman.net Mon Jul 19 21:11:23 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 19 Jul 2010 15:11:23 -0400 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <201007192015.37663.smueller@chronox.de> References: <1279290308.1880.65.camel@tauon> <1279308575.1880.81.camel@tauon> <4C448D96.7090209@fifthhorseman.net> <201007192015.37663.smueller@chronox.de> Message-ID: <4C44A35B.3010706@fifthhorseman.net> On 07/19/2010 02:15 PM, Stephan Mueller wrote: > Both, there is the root cert (and I concur with your assessment), but there > are also intermediate certs with MD2 too. intermediate certs using MD2 should themselves be considered broken, as certifications from root CAs over MD2 are susceptible to a preimage attack: http://en.wikipedia.org/wiki/MD2_%28cryptography%29#Security It would be a bad thing to accept intermediate certificates over the network that were certified with MD2. If you're talking about shipping certs of known intermediate authorities as part of a package of trusted authorities, then those are actually equivalent to root authorities, not intermediate authorities (even if their own certs are not self-signed). > Well, Werner already told me that he is not integrating the patches. However, > as the patches only enable the signature verification of an already existing > signature, I cannot fully understand the decision. Are the patches rejected due to poor implementation? due to licensing reasons? or due to a desire to not ship the MD2 functionality in libgcrypt? or due to some other reason? sorry for having to ask, but i never saw a response on the list, so i'm in the dark. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From smueller at chronox.de Tue Jul 20 07:21:33 2010 From: smueller at chronox.de (Stephan Mueller) Date: Tue, 20 Jul 2010 07:21:33 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <4C44A35B.3010706@fifthhorseman.net> References: <1279290308.1880.65.camel@tauon> <201007192015.37663.smueller@chronox.de> <4C44A35B.3010706@fifthhorseman.net> Message-ID: <201007200721.34124.smueller@chronox.de> Am Montag 19 Juli 2010, um 21:11:23 schrieb Daniel Kahn Gillmor: > On 07/19/2010 02:15 PM, Stephan Mueller wrote: > > Both, there is the root cert (and I concur with your assessment), but > > there are also intermediate certs with MD2 too. > > intermediate certs using MD2 should themselves be considered broken, as > certifications from root CAs over MD2 are susceptible to a preimage attack: > > http://en.wikipedia.org/wiki/MD2_%28cryptography%29#Security > > It would be a bad thing to accept intermediate certificates over the > network that were certified with MD2. > > If you're talking about shipping certs of known intermediate authorities > as part of a package of trusted authorities, then those are actually > equivalent to root authorities, not intermediate authorities (even if > their own certs are not self-signed). I am totally on your side. I dislike MD2 as anybody else. But I am also a realist. Verisign certs are pervasive. So, we have to live with it. I personally made the effort to integrate MD2 to switch back to my favorite MUA which happens to use gpgsm. But still, I have to be able to handle certificates signed with Verisign's CA. Of course, it would be possible to simply import the user's certs, verify them manually and add the fingerprint to gpgsm's trustlist.txt manually. But really, which normal user is really able to do that? Besides, wouldn't such an approach defy the SMIME key management approach? > > > Well, Werner already told me that he is not integrating the patches. > > However, as the patches only enable the signature verification of an > > already existing signature, I cannot fully understand the decision. > > Are the patches rejected due to poor implementation? due to licensing > reasons? or due to a desire to not ship the MD2 functionality in > libgcrypt? or due to some other reason? > > sorry for having to ask, but i never saw a response on the list, so i'm > in the dark. He did not say, but I guess it is because of the poor reputation of MD2. I would have no problems when MD2 in general is somehow not fully exported via the libgcrypt API for general use. All I need and all I want is MD2 for using it with gpgsm for verification of existing certificates. Just in case someone asks: the entire MD2 implementation is derived straight from NSS. That is why the functions MD2_* and md2_compress have a different indentation style than the rest of libgcrypt. I deliberately did not change that to keep a one-to-one copy from NSS. libgcrypt-specific additions are clearly visible at the end of the C file and the massaging of the other function's input parameters. Ciao Stephan > > --dkg From dkg at fifthhorseman.net Tue Jul 20 07:53:14 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 20 Jul 2010 01:53:14 -0400 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <201007200721.34124.smueller@chronox.de> References: <1279290308.1880.65.camel@tauon> <201007192015.37663.smueller@chronox.de> <4C44A35B.3010706@fifthhorseman.net> <201007200721.34124.smueller@chronox.de> Message-ID: <4C4539CA.9040001@fifthhorseman.net> On 07/20/2010 01:21 AM, Stephan Mueller wrote: > I am totally on your side. I dislike MD2 as anybody else. But I am also a > realist. Verisign certs are pervasive. So, we have to live with it. if "live with it" means accepting arbitrary certifications over MD2 digests, i really think this is not acceptable. Please don't advocate for this. if "live with it" means shipping full copies of a set of well-known, widely-used verisign intermediate CA certs as root authorities, then i don't think it's significantly worse than shipping verisign's canonical root ca cert in the first place. (which is not to say i advocate relying on certifications made by Verisign). > Of course, it would be possible to simply import the user's certs, verify them > manually and add the fingerprint to gpgsm's trustlist.txt manually. But > really, which normal user is really able to do that? Besides, wouldn't such an > approach defy the SMIME key management approach? i don't know what the SMIME key management approach is. > He did not say, Werner, would you care to comment on-list? Maybe if the reason for your rejection was public, Stephan (or someone else) would modify the patch to address it. > but I guess it is because of the poor reputation of MD2. If we're talking about gcrypt (this is the gcrypt-devel list, so i assume we are), that wouldn't make much sense, given that there are extremely weak digests like CRC32 included in libgcrypt. accepting certifications over MD2 in security-sensitive libraries like gnutls and gnupg is another matter, of course. But as a library of crypto-primitives that implements a range of digest functions, having an MD2 implementation doesn't seem unreasonable. > I > would have no problems when MD2 in general is somehow not fully exported via > the libgcrypt API for general use. All I need and all I want is MD2 for using > it with gpgsm for verification of existing certificates. I would resist this on the grounds that assertions backed only by an MD2 digest are computationally suspect. They're just too easy to forge/replay. Would you advocate accepting certificates made over a CRC32 digest? If so, why bother with certificates in the first place? > Just in case someone asks: the entire MD2 implementation is derived straight > from NSS. That is why the functions MD2_* and md2_compress have a different > indentation style than the rest of libgcrypt. I deliberately did not change > that to keep a one-to-one copy from NSS. libgcrypt-specific additions are > clearly visible at the end of the C file and the massaging of the other > function's input parameters. Given this background (and the probably-low likelihood that the NSS authors are willing to assign copyright to the FSF), i wonder if Werner's concerns are licensing concerns. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From smueller at chronox.de Tue Jul 20 08:53:08 2010 From: smueller at chronox.de (Stephan Mueller) Date: Tue, 20 Jul 2010 08:53:08 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <4C4539CA.9040001@fifthhorseman.net> References: <1279290308.1880.65.camel@tauon> <201007200721.34124.smueller@chronox.de> <4C4539CA.9040001@fifthhorseman.net> Message-ID: <201007200853.08297.smueller@chronox.de> Am Dienstag 20 Juli 2010, um 07:53:14 schrieb Daniel Kahn Gillmor: > On 07/20/2010 01:21 AM, Stephan Mueller wrote: > > I am totally on your side. I dislike MD2 as anybody else. But I am also a > > realist. Verisign certs are pervasive. So, we have to live with it. > > if "live with it" means accepting arbitrary certifications over MD2 > digests, i really think this is not acceptable. Please don't advocate > for this. I meant to say that we have to live with Verisign CA certificates as we cannot change them. But I would not want to suggest using MD2 for anything else. > > if "live with it" means shipping full copies of a set of well-known, > widely-used verisign intermediate CA certs as root authorities, then i > don't think it's significantly worse than shipping verisign's canonical > root ca cert in the first place. (which is not to say i advocate > relying on certifications made by Verisign). Sounds good. I just rechecked all the Verisign certs: what I said initially was not correct. Only some of the root CA certificates, but no intermediate CA certificate rely on MD2. The intemediate certificates use SHA1, MD5. > > > Of course, it would be possible to simply import the user's certs, verify > > them manually and add the fingerprint to gpgsm's trustlist.txt manually. > > But really, which normal user is really able to do that? Besides, > > wouldn't such an approach defy the SMIME key management approach? > > i don't know what the SMIME key management approach is. You rely on the CA for establishing trust into the certificates you obtain from other (potentically unknown) users. > > > He did not say, > > Werner, would you care to comment on-list? Maybe if the reason for your > rejection was public, Stephan (or someone else) would modify the patch > to address it. > > > but I guess it is because of the poor reputation of MD2. > > If we're talking about gcrypt (this is the gcrypt-devel list, so i > assume we are), that wouldn't make much sense, given that there are > extremely weak digests like CRC32 included in libgcrypt. > > accepting certifications over MD2 in security-sensitive libraries like > gnutls and gnupg is another matter, of course. But as a library of > crypto-primitives that implements a range of digest functions, having an > MD2 implementation doesn't seem unreasonable. > > > I > > would have no problems when MD2 in general is somehow not fully exported > > via the libgcrypt API for general use. All I need and all I want is MD2 > > for using it with gpgsm for verification of existing certificates. > > I would resist this on the grounds that assertions backed only by an MD2 > digest are computationally suspect. They're just too easy to > forge/replay. Would you advocate accepting certificates made over a > CRC32 digest? If so, why bother with certificates in the first place? Considering CRC32 which is generally available, I would then also not suggest treating MD2 special just because it happens to be weak. > > > Just in case someone asks: the entire MD2 implementation is derived > > straight from NSS. That is why the functions MD2_* and md2_compress have > > a different indentation style than the rest of libgcrypt. I deliberately > > did not change that to keep a one-to-one copy from NSS. > > libgcrypt-specific additions are clearly visible at the end of the C > > file and the massaging of the other function's input parameters. > > Given this background (and the probably-low likelihood that the NSS > authors are willing to assign copyright to the FSF), i wonder if > Werner's concerns are licensing concerns. Is it necessary that the rights have to go to FSF? There is only one additional file that has a special copyright. A lot of open source projects have different licensing terms for different parts. The code is (L)GPL2 as outlined in the header of the file which again is taken verbatim from NSS. Ciao Stephan > > --dkg Ciao Stephan From wk at gnupg.org Tue Jul 20 09:11:08 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Jul 2010 09:11:08 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <4C44A35B.3010706@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 19 Jul 2010 15:11:23 -0400") References: <1279290308.1880.65.camel@tauon> <1279308575.1880.81.camel@tauon> <4C448D96.7090209@fifthhorseman.net> <201007192015.37663.smueller@chronox.de> <4C44A35B.3010706@fifthhorseman.net> Message-ID: <87wrsqiq5v.fsf@vigenere.g10code.de> On Mon, 19 Jul 2010 21:11, dkg at fifthhorseman.net said: > Are the patches rejected due to poor implementation? due to licensing > reasons? or due to a desire to not ship the MD2 functionality in The MD2 things comes up every few years and we have always rejected it. For one the legal state of the algorithm is not clear: It is likely that it has been taken from the RFC which has a non-commercial clause. In this regard it is similar to arcfour. The GNU project is very cautiousness on these issues and thus we would need to clear the legal state first (meaning long dicussions with RSA Inc). I don't think this is justified. And of course we need a copyright assignment and code which is clearly not based on rfc 1319. The other reasons is that I don't want to keep those old certificates alive. They should have been abolished a long time ago. IMHO there is no good reason to use them (Sorry, Stefan). Getting certificates for S/MIME is not hard and actually pretty cheap these days. A counterpoint would be that the whole X.509 PKI business is entirely broken and does not provide any security at all. You only need to look at a few of the implementation problems identified in the last years. Thus why not add support for it - it won't make it worse. But see the first point. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From smueller at chronox.de Tue Jul 20 10:09:17 2010 From: smueller at chronox.de (Stephan Mueller) Date: Tue, 20 Jul 2010 10:09:17 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <87wrsqiq5v.fsf@vigenere.g10code.de> References: <1279290308.1880.65.camel@tauon> <4C44A35B.3010706@fifthhorseman.net> <87wrsqiq5v.fsf@vigenere.g10code.de> Message-ID: <201007201009.18272.smueller@chronox.de> Am Dienstag 20 Juli 2010, um 09:11:08 schrieb Werner Koch: > On Mon, 19 Jul 2010 21:11, dkg at fifthhorseman.net said: > > Are the patches rejected due to poor implementation? due to licensing > > reasons? or due to a desire to not ship the MD2 functionality in > > The MD2 things comes up every few years and we have always rejected it. > > For one the legal state of the algorithm is not clear: It is likely that > it has been taken from the RFC which has a non-commercial clause. In > this regard it is similar to arcfour. The GNU project is very > cautiousness on these issues and thus we would need to clear the legal > state first (meaning long dicussions with RSA Inc). I don't think this > is justified. And of course we need a copyright assignment and code > which is clearly not based on rfc 1319. > > The other reasons is that I don't want to keep those old certificates > alive. They should have been abolished a long time ago. IMHO there is > no good reason to use them (Sorry, Stefan). Getting certificates for > S/MIME is not hard and actually pretty cheap these days. I know, but tell that to my counterparts! > > A counterpoint would be that the whole X.509 PKI business is entirely > broken and does not provide any security at all. You only need to look > at a few of the implementation problems identified in the last years. > Thus why not add support for it - it won't make it worse. But see the > first point. > Ok, may I then ask that you add a pointer to my patches in your documentation (I will give you the URL of my web page which will also contain a polished version of the patches)? I just want people to give a chance using gpgsm when they need to rely on MD2. Ciao Stephan -- | Cui bono? | From vapier at gentoo.org Tue Jul 20 00:54:35 2010 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 19 Jul 2010 18:54:35 -0400 Subject: Blackfin and version scripts In-Reply-To: <201007061308.28256.vapier@gentoo.org> References: <87pqzjqu7g.fsf@vigenere.g10code.de> <20100706163413.GA1420@roeckx.be> <201007061308.28256.vapier@gentoo.org> Message-ID: <201007191854.37898.vapier@gentoo.org> On Tuesday, July 06, 2010 13:08:26 Mike Frysinger wrote: > On Tuesday, July 06, 2010 12:34:13 Kurt Roeckx wrote: > > But my point is that a version script is nothing arch specific, > > unlike a linker script. Version scripts even support saying in > > which language the symbol is, so that it can properly mangle it > > for you. Adding the symbol inside an 'extern "C"' also doesn't > > have any effect. > > with no lang spec, it is arch specific because it is dealing in linker > visible symbols. you are correct that 'extern "C"' should work though. after talking with the binutils guys, they seem to agree with you about the default language is "C" and not "linker visible". so i'll pursue that course. thanks for the push. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Tue Jul 20 17:15:15 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 20 Jul 2010 11:15:15 -0400 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <87wrsqiq5v.fsf@vigenere.g10code.de> References: <1279290308.1880.65.camel@tauon> <1279308575.1880.81.camel@tauon> <4C448D96.7090209@fifthhorseman.net> <201007192015.37663.smueller@chronox.de> <4C44A35B.3010706@fifthhorseman.net> <87wrsqiq5v.fsf@vigenere.g10code.de> Message-ID: <4C45BD83.5050407@fifthhorseman.net> On 07/20/2010 03:11 AM, Werner Koch wrote: > For one the legal state of the algorithm is not clear: It is likely that > it has been taken from the RFC which has a non-commercial clause. In > this regard it is similar to arcfour. The GNU project is very > cautiousness on these issues and thus we would need to clear the legal > state first (meaning long dicussions with RSA Inc). I don't think this > is justified. And of course we need a copyright assignment and code > which is clearly not based on rfc 1319. Maybe the docs could indicate this somehow? currently the manual [0] only says: GCRY_MD_MD2 This is an reserved identifier for MD-2; there is no implementation yet. This algorithm has severe weaknesses and should not be used. an additional concise note about the specific legal encumbrances you're worried about might save other implementors time in the future (and might lead to a resolution of those legal concerns). > The other reasons is that I don't want to keep those old certificates > alive. I agree with you here. but that's not an argument for not including MD2 in libgcrypt. libgcrypt provides cryptographic primitives, not X.509 business. the more crypto primitives it can offer, the more attractive it is as a library. > A counterpoint would be that the whole X.509 PKI business is entirely > broken and does not provide any security at all. agreed, sadly. --dkg [0] http://www.gnupg.org/documentation/manuals/gcrypt/Available-hash-algorithms.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From n3npq at mac.com Tue Jul 20 17:54:49 2010 From: n3npq at mac.com (Jeff Johnson) Date: Tue, 20 Jul 2010 11:54:49 -0400 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <4C45BD83.5050407@fifthhorseman.net> References: <1279290308.1880.65.camel@tauon> <1279308575.1880.81.camel@tauon> <4C448D96.7090209@fifthhorseman.net> <201007192015.37663.smueller@chronox.de> <4C44A35B.3010706@fifthhorseman.net> <87wrsqiq5v.fsf@vigenere.g10code.de> <4C45BD83.5050407@fifthhorseman.net> Message-ID: <9CE66209-3F0B-4137-B62B-896E2549EC97@mac.com> On Jul 20, 2010, at 11:15 AM, Daniel Kahn Gillmor wrote: > On 07/20/2010 03:11 AM, Werner Koch wrote: >> For one the legal state of the algorithm is not clear: It is likely that >> it has been taken from the RFC which has a non-commercial clause. In >> this regard it is similar to arcfour. The GNU project is very >> cautiousness on these issues and thus we would need to clear the legal >> state first (meaning long dicussions with RSA Inc). I don't think this >> is justified. And of course we need a copyright assignment and code >> which is clearly not based on rfc 1319. > > Maybe the docs could indicate this somehow? currently the manual [0] > only says: > > GCRY_MD_MD2 > This is an reserved identifier for MD-2; there is no implementation > yet. This algorithm has severe weaknesses and should not be used. > > an additional concise note about the specific legal encumbrances you're > worried about might save other implementors time in the future (and > might lead to a resolution of those legal concerns). > Documenting doesn't resolve the issue. As already reported, RFE for MD2 -> libgcrypt comes along regular as clockwork every few years with sound reasons supporting every possible POV. >> The other reasons is that I don't want to keep those old certificates >> alive. > > I agree with you here. but that's not an argument for not including MD2 > in libgcrypt. libgcrypt provides cryptographic primitives, not X.509 > business. the more crypto primitives it can offer, the more attractive > it is as a library. > Well I can give you the counter example that proves the rule that more primitives != more attractive. RPM includes >100 hashes, with test vectors, for all possible NIST SHA3 selections. That doesn't make RPM any more attractive than any other crypto library. Hint: Try baseball card collecting instead. Unlike crypto hashes, you get to shuffle or sell the collection whenever you wish, and baseball cards come with pictures and batting averages that are easier to reason with than "secure" metrics. >> A counterpoint would be that the whole X.509 PKI business is entirely >> broken and does not provide any security at all. > > agreed, sadly. > Also agreed. But X.509 is most definitely something that cannot be just ignored. On a more optimistic forward looking note: What is the better answer if X.509 is sadly pathetic? 73 de Jeff From smueller at chronox.de Tue Jul 20 18:40:53 2010 From: smueller at chronox.de (Stephan Mueller) Date: Tue, 20 Jul 2010 18:40:53 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <9CE66209-3F0B-4137-B62B-896E2549EC97@mac.com> References: <1279290308.1880.65.camel@tauon> <4C45BD83.5050407@fifthhorseman.net> <9CE66209-3F0B-4137-B62B-896E2549EC97@mac.com> Message-ID: <201007201840.53779.smueller@chronox.de> Am Dienstag 20 Juli 2010, um 17:54:49 schrieb Jeff Johnson: Hi Jeff, > On Jul 20, 2010, at 11:15 AM, Daniel Kahn Gillmor wrote: > > On 07/20/2010 03:11 AM, Werner Koch wrote: > >> For one the legal state of the algorithm is not clear: It is likely that > >> it has been taken from the RFC which has a non-commercial clause. In > >> this regard it is similar to arcfour. The GNU project is very > >> cautiousness on these issues and thus we would need to clear the legal > >> state first (meaning long dicussions with RSA Inc). I don't think this > >> is justified. And of course we need a copyright assignment and code > >> which is clearly not based on rfc 1319. > > > > Maybe the docs could indicate this somehow? currently the manual [0] > > only says: > > > > GCRY_MD_MD2 > > > > This is an reserved identifier for MD-2; there is no implementation > > > > yet. This algorithm has severe weaknesses and should not be used. > > > > an additional concise note about the specific legal encumbrances you're > > worried about might save other implementors time in the future (and > > might lead to a resolution of those legal concerns). > > Documenting doesn't resolve the issue. As already reported, RFE for > MD2 -> libgcrypt comes along regular as clockwork every few years > with sound reasons supporting every possible POV. Only this time, we have a working implementation :-) Ciao Stephan -- | Cui bono? | From n3npq at mac.com Tue Jul 20 18:45:30 2010 From: n3npq at mac.com (Jeff Johnson) Date: Tue, 20 Jul 2010 12:45:30 -0400 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <201007201840.53779.smueller@chronox.de> References: <1279290308.1880.65.camel@tauon> <4C45BD83.5050407@fifthhorseman.net> <9CE66209-3F0B-4137-B62B-896E2549EC97@mac.com> <201007201840.53779.smueller@chronox.de> Message-ID: On Jul 20, 2010, at 12:40 PM, Stephan Mueller wrote: >>> >> >> Documenting doesn't resolve the issue. As already reported, RFE for >> MD2 -> libgcrypt comes along regular as clockwork every few years >> with sound reasons supporting every possible POV. > > Only this time, we have a working implementation :-) > Hint: track how IDEA was wired into gnupg way back when, should work for MD2 almost as easily. wk isn't wrong. 73 de Jeff From smueller at chronox.de Tue Jul 20 18:52:51 2010 From: smueller at chronox.de (Stephan Mueller) Date: Tue, 20 Jul 2010 18:52:51 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <4C45BD83.5050407@fifthhorseman.net> References: <1279290308.1880.65.camel@tauon> <87wrsqiq5v.fsf@vigenere.g10code.de> <4C45BD83.5050407@fifthhorseman.net> Message-ID: <201007201852.51661.smueller@chronox.de> Am Dienstag 20 Juli 2010, um 17:15:15 schrieb Daniel Kahn Gillmor: Hi Daniel, > On 07/20/2010 03:11 AM, Werner Koch wrote: > > For one the legal state of the algorithm is not clear: It is likely that > > it has been taken from the RFC which has a non-commercial clause. In > > this regard it is similar to arcfour. The GNU project is very > > cautiousness on these issues and thus we would need to clear the legal > > state first (meaning long dicussions with RSA Inc). I don't think this > > is justified. And of course we need a copyright assignment and code > > which is clearly not based on rfc 1319. > > Maybe the docs could indicate this somehow? currently the manual [0] > only says: > > GCRY_MD_MD2 > This is an reserved identifier for MD-2; there is no implementation > yet. This algorithm has severe weaknesses and should not be used. > > an additional concise note about the specific legal encumbrances you're > worried about might save other implementors time in the future (and > might lead to a resolution of those legal concerns). Well, I would have done the implementation/port of MD2 anyway as it is relatively simple, because I need it for SMIME as I pointed out. The only sad thing is that SMIME of gpgsm is not complete without MD2. I want people to use libgcrypt and gpgsm simply because libgcrypt is one of the cleanest and best written crypto libs I know of. And I know quite a number indepth (Werner can tell). > > A counterpoint would be that the whole X.509 PKI business is entirely > > broken and does not provide any security at all. > > agreed, sadly. Yes, agreed from my side as well. But what can you do if customers force you to use it, even with MD2? Ciao Stephan -- | Cui bono? | From dkg at fifthhorseman.net Tue Jul 20 19:18:35 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 20 Jul 2010 13:18:35 -0400 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <9CE66209-3F0B-4137-B62B-896E2549EC97@mac.com> References: <1279290308.1880.65.camel@tauon> <1279308575.1880.81.camel@tauon> <4C448D96.7090209@fifthhorseman.net> <201007192015.37663.smueller@chronox.de> <4C44A35B.3010706@fifthhorseman.net> <87wrsqiq5v.fsf@vigenere.g10code.de> <4C45BD83.5050407@fifthhorseman.net> <9CE66209-3F0B-4137-B62B-896E2549EC97@mac.com> Message-ID: <4C45DA6B.1000408@fifthhorseman.net> On 07/20/2010 11:54 AM, Jeff Johnson wrote: > Documenting doesn't resolve the issue. As already reported, RFE for > MD2 -> libgcrypt comes along regular as clockwork every few years > with sound reasons supporting every possible POV. so, if we can avoid legal encumbrances, and given that we already support extremely weak digests like CRC32, why not merge in MD2, given that there is obvious demand for it (the "clockwork")? If the answer is "no, we will never have MD2 in gcrypt, ever", then that should be documented as well. The current docs look like it's just not implemented yet. > RPM includes >100 hashes, with test vectors, for all possible NIST SHA3 > selections. That doesn't make RPM any more attractive than any other > crypto library. I wasn't aware that RPM actually offered a crypto primitive library. if that library also includes ciphers and asymmetric crypto, all under a reasonable license, i'd consider it very attractive indeed. Is this in librpm or something? > Hint: Try baseball card collecting instead. Unlike crypto hashes, > you get to shuffle or sell the collection whenever you wish, and > baseball cards come with pictures and batting averages that are > easier to reason with than "secure" metrics. I don't understand this remark, sorry. I don't have a "collect them all" mentality about algorithms. But i would expect a suite of cryptographic primitives to want to provide reasonable coverage of commonly requested algorithms. If we were interested in only providing the most secure algorithms, we'd have dropped MD5 and maybe even SHA1 by now. That wouldn't make for a very useful crypto library, and people would not want to use it. I'm *not* arguing for accepting non-root certificates made over MD2 digesets at higher layers than gcrypt. I'm just arguing for reasonable inclusion of commonly requested algorithms in a toolkit of those algorithms. > On a more optimistic forward looking note: > What is the better answer if X.509 is sadly pathetic? The Monkeysphere project treats X.509 certificates as basically meaningless packaging around RSA public key material, and looks up certifications over the same key material in the OpenPGP web of trust instead. While OpenPGP has its problems, it resolves some of the major problems of X.509. In particular, it resolves X.509's requirement of a single-certifier, which i think is at the root of much of the institutionalized insecurity. We're probably getting OT for this list -- if you want to discuss ideas like this about how to move forward, i invite you to join the monkeysphere mailing list and IRC channel. Details can be found at: http://web.monkeysphere.info/community Thanks for the discussion, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sat Jul 24 08:51:47 2010 From: wk at gnupg.org (Werner Koch) Date: Sat, 24 Jul 2010 08:51:47 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <201007200853.08297.smueller@chronox.de> (Stephan Mueller's message of "Tue\, 20 Jul 2010 08\:53\:08 +0200") References: <1279290308.1880.65.camel@tauon> <201007200721.34124.smueller@chronox.de> <4C4539CA.9040001@fifthhorseman.net> <201007200853.08297.smueller@chronox.de> Message-ID: <87sk391if0.fsf@wheatstone.g10code.de> Stephan Mueller writes: > Is it necessary that the rights have to go to FSF? There is only one > additional file that has a special copyright. A lot of open source projects > have different licensing terms for different parts. Yes. The GNU project tries to minimize legal irregularities due to different copyright holders. In important cases we can make exceptions but MD2 does not seem a good reason. Writing an MD2 implementation from a public source like the description given in Wikipedia does not seem to be a complicated task. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Jul 24 08:35:31 2010 From: wk at gnupg.org (Werner Koch) Date: Sat, 24 Jul 2010 08:35:31 +0200 Subject: Blackfin and version scripts In-Reply-To: <20100626193605.GA11797@gmx.de> (Ralf Wildenhues's message of "Sat\, 26 Jun 2010 21\:36\:08 +0200") References: <87pqzjqu7g.fsf@vigenere.g10code.de> <20100626193605.GA11797@gmx.de> Message-ID: <87y6d1v13g.fsf@wheatstone.g10code.de> Hi! Ralf Wildenhues wrote on June 26: > - complex GNU/Solaris ld version scripts, but most users need only a > fairly simple part of that, > - w32 .def files, > - symbols lists or regexes as used by libtool, > - the wild card specification to use: ld uses globbing, > -export-symbols-regex uses ERE. > - mangling relevant also for C: prepending underscore or not, appending > calling convention suffixes @... on w32, > - mangling for non-C languages: C++, Java, > - libtool should be able to add or remove a few symbols to the list, > - for w32, we may need to tag DATA exports, For W32 we also need the ability to assign ordinal numbers. Actually this is more important than the calling convention suffix because allmost all new libs use C style. For example: DllRegisterServer = DllRegisterServer at 0 @2 PRIVATE Which assigns the ordinal 2 to DllRegisterServer. I don't think the complex syntax given above is really needed but nevertheless ordinals are important to keep the ABI consistent, Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Jul 24 08:58:08 2010 From: wk at gnupg.org (Werner Koch) Date: Sat, 24 Jul 2010 08:58:08 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <4C45DA6B.1000408@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue\, 20 Jul 2010 13\:18\:35 -0400") References: <1279290308.1880.65.camel@tauon> <1279308575.1880.81.camel@tauon> <4C448D96.7090209@fifthhorseman.net> <201007192015.37663.smueller@chronox.de> <4C44A35B.3010706@fifthhorseman.net> <87wrsqiq5v.fsf@vigenere.g10code.de> <4C45BD83.5050407@fifthhorseman.net> <9CE66209-3F0B-4137-B62B-896E2549EC97@mac.com> <4C45DA6B.1000408@fifthhorseman.net> Message-ID: <87ocdx1i4f.fsf@wheatstone.g10code.de> Daniel Kahn Gillmor writes: > so, if we can avoid legal encumbrances, and given that we already > support extremely weak digests like CRC32, why not merge in MD2, given CRC32 is not a digest but a CRC. The reason that it uses the digest franework is simply that the API requirements are identical. It should be clear to everyone with a little experience that a CRC is something different than a crypto hash. > digesets at higher layers than gcrypt. I'm just arguing for reasonable > inclusion of commonly requested algorithms in a toolkit of those algorithms. Okay, write an implementation we can assign to the FSF and it will go into libgcrypt. Don't take it from the RFC, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Jul 24 09:05:01 2010 From: wk at gnupg.org (Werner Koch) Date: Sat, 24 Jul 2010 09:05:01 +0200 Subject: [PATCH] MD2 for libgcrypt In-Reply-To: <201007201852.51661.smueller@chronox.de> (Stephan Mueller's message of "Tue\, 20 Jul 2010 18\:52\:51 +0200") References: <1279290308.1880.65.camel@tauon> <87wrsqiq5v.fsf@vigenere.g10code.de> <4C45BD83.5050407@fifthhorseman.net> <201007201852.51661.smueller@chronox.de> Message-ID: <87k4ol1hsy.fsf@wheatstone.g10code.de> Stephan Mueller writes: > Yes, agreed from my side as well. But what can you do if customers force you > to use it, even with MD2? An option might be to add flag to trustlist.txt, similar to "relax", which suppresses validation of the root certificate. I agree that validation of the root certifciate is not necessary because we check the fingerprint anyway. However that extra check revealed some probelms in the past and thus I don't want to drop it completely. I can't remeber but there might have been a specification which required this validation. This won't help Daniel's request for adding a MD2 to use libgcrypt as a crypto bench. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupg at oneiroi.net Sat Jul 24 12:37:49 2010 From: gnupg at oneiroi.net (Milo) Date: Sat, 24 Jul 2010 12:37:49 +0200 Subject: Gcrypt-devel Digest, Vol 66, Issue 5 In-Reply-To: References: Message-ID: <4C4AC27D.5000409@oneiroi.net> On 07/24/2010 10:36 AM, gcrypt-devel-request at gnupg.org wrote: >> A counterpoint would be that the whole X.509 PKI business is entirely >> broken and does not provide any security at all. > > agreed, sadly. > > --dkg "whole X.509 PKI business is broken and does not provide any security at all" - very interesting statement. Could you elaborate on that? -- Regards, Milo From gnupg at oneiroi.net Sat Jul 24 23:37:02 2010 From: gnupg at oneiroi.net (Milo) Date: Sat, 24 Jul 2010 23:37:02 +0200 Subject: [PATCH] MD2 for libgcrypt (Daniel Kahn Gillmor) In-Reply-To: References: Message-ID: <4C4B5CFE.2060603@oneiroi.net> On 07/24/2010 10:36 AM, gcrypt-devel-request at gnupg.org wrote: > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 20 Jul 2010 11:15:15 -0400 > From: Daniel Kahn Gillmor > To: Stephan Mueller, gcrypt-devel at gnupg.org > Subject: Re: [PATCH] MD2 for libgcrypt > Message-ID:<4C45BD83.5050407 at fifthhorseman.net> > Content-Type: text/plain; charset="utf-8" > > (...) > >> A counterpoint would be that the whole X.509 PKI business is entirely >> broken and does not provide any security at all. > > agreed, sadly. > > --dkg Hello. (Sorry for last post lacking proper topic; just in case - second try). "the whole X.509 PKI business is entirely broken and does not provide any security at all" - very interesting statement. Could you elaborate on that? -- Regards, Milo From dkg at fifthhorseman.net Sun Jul 25 04:07:30 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 24 Jul 2010 22:07:30 -0400 Subject: OT: problems with the X.509 PKI business [was: Re: Gcrypt-devel Digest, Vol 66, Issue 5] In-Reply-To: <4C4AC27D.5000409@oneiroi.net> References: <4C4AC27D.5000409@oneiroi.net> Message-ID: <4C4B9C62.8070102@fifthhorseman.net> On 07/24/2010 06:37 AM, Milo wrote: > On 07/24/2010 10:36 AM, gcrypt-devel-request at gnupg.org wrote: > >>> A counterpoint would be that the whole X.509 PKI business is entirely >>> broken and does not provide any security at all. >> >> agreed, sadly. > > "whole X.509 PKI business is broken and does not provide any security at > all" - very interesting statement. Could you elaborate on that? For one example, X.509 sets up a situation that encourages centralized, hierarchical reliance on an unaccountable cabal of Certificate Authorities: http://lair.fifthhorseman.net/~dkg/tls-centralization/ --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From linux at paip.net Sun Jul 25 06:41:26 2010 From: linux at paip.net (Ian Goldberg) Date: Sun, 25 Jul 2010 00:41:26 -0400 Subject: OT: problems with the X.509 PKI business [was: Re: Gcrypt-devel Digest, Vol 66, Issue 5] Message-ID: <20100725044126.GA11641@paip.net> On Sat, Jul 24, 2010 at 10:07:30PM -0400, Daniel Kahn Gillmor wrote: > On 07/24/2010 06:37 AM, Milo wrote: > > On 07/24/2010 10:36 AM, gcrypt-devel-request at gnupg.org wrote: > > > >>> A counterpoint would be that the whole X.509 PKI business is entirely > >>> broken and does not provide any security at all. > >> > >> agreed, sadly. > > > > > "whole X.509 PKI business is broken and does not provide any security at > > all" - very interesting statement. Could you elaborate on that? > > For one example, X.509 sets up a situation that encourages centralized, > hierarchical reliance on an unaccountable cabal of Certificate Authorities: > > http://lair.fifthhorseman.net/~dkg/tls-centralization/ It's way, way worse than that. No only are there are over 250 root CAs that some browsers trust, but those CAs have signed an (unknown!) number of intermediate certificates, _any_ of which can be used to sign a certificate for _any_ domain. See for example http://petsymposium.org/2010/papers/hotpets10-Soghoian.pdf which was presented at HotPETs in Berlin just this past Friday. - Ian From john at johnandjuliet.com Tue Jul 27 15:34:39 2010 From: john at johnandjuliet.com (john at johnandjuliet.com) Date: Tue, 27 Jul 2010 06:34:39 -0700 Subject: Use of libgcrypt in non-OS platforms Message-ID: <20100727063439.98fd97237cc930a62b888eb89e535f85.fea4d367a6.wbe@email12.secureserver.net> An HTML attachment was scrubbed... URL: From dank at kegel.com Tue Jul 27 17:43:10 2010 From: dank at kegel.com (Dan Kegel) Date: Tue, 27 Jul 2010 08:43:10 -0700 Subject: Use of libgcrypt in non-OS platforms In-Reply-To: <20100727063439.98fd97237cc930a62b888eb89e535f85.fea4d367a6.wbe@email12.secureserver.net> References: <20100727063439.98fd97237cc930a62b888eb89e535f85.fea4d367a6.wbe@email12.secureserver.net> Message-ID: On Tue, Jul 27, 2010 at 6:34 AM, wrote: > 2) Though I like the cause of the GNU projects some of my code is not to be > given out (purchased) and so if I try to use libg-crypt I realize I would > need to somehow follow the GNU license.? But I need to do it in a way that > does not cause the rest of my code to turn into GNU or break my contract > with the other code I am using.? So the question is what is the > ramifications of using just the lib instead of the entire tool (which would > require running linux which I cant do). That's a tough question, but: the intent of the LGPL is to allow people to fix bugs in software they use. If you provide a way for people to replace the libgcrypt in your system with one that they provide themselves, that might satisfy the dynamic linking requirement. But don't trust what I say, I am not a lawyer. - Dan