From ametzler at downhill.at.eu.org Sat Jul 2 13:22:11 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 2 Jul 2011 13:22:11 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 In-Reply-To: <20110702102734.GA2013@downhill.g.la> References: <20110702102734.GA2013@downhill.g.la> Message-ID: <20110702112211.GB2013@downhill.g.la> On 2011-07-02 Andreas Metzler wrote: > ugrading libgcrypt from 1.4.6 to 1.5.0 causes 5 new test suite errors > in gnutls 2.17.1: [...] This is new breakage, building against 1.5.0beta1 works. cu andreas -- `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 ametzler at downhill.at.eu.org Sat Jul 2 12:27:34 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 2 Jul 2011 12:27:34 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 Message-ID: <20110702102734.GA2013@downhill.g.la> Hello, ugrading libgcrypt from 1.4.6 to 1.5.0 causes 5 new test suite errors in gnutls 2.17.1: ------------------------- PASS: pgps2kgnu client: Handshake failed server: Handshake has failed (The request is invalid.) GnuTLS error: A TLS packet with unexpected length was received. Self test `./x509self' finished with 1 errors Self test `./x509self' finished with 1 errors FAIL: x509self client: Handshake failed server: Handshake has failed (The request is invalid.) GnuTLS error: A TLS packet with unexpected length was received. Self test `./x509dn' finished with 1 errors server: client failed with exit status 1 Self test `./x509dn' finished with 2 errors FAIL: x509dn Self test `./anonself' finished with 0 errors [...] PASS: setcredcrash client: Handshake 0 failed server: Handshake 0 has failed (The request is invalid.) GnuTLS error: A TLS packet with unexpected length was received. Self test `./openpgpself' finished with 1 errors Self test `./openpgpself' finished with 1 errors FAIL: openpgpself PASS: rfc2253-escape-test ------------------------- cu andreas -- `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 wk at gnupg.org Sat Jul 2 14:23:05 2011 From: wk at gnupg.org (Werner Koch) Date: Sat, 02 Jul 2011 14:23:05 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 In-Reply-To: <20110702112211.GB2013@downhill.g.la> (Andreas Metzler's message of "Sat, 2 Jul 2011 13:22:11 +0200") References: <20110702102734.GA2013@downhill.g.la> <20110702112211.GB2013@downhill.g.la> Message-ID: <87y60geus6.fsf@vigenere.g10code.de> On Sat, 2 Jul 2011 13:22, ametzler at downhill.at.eu.org said: > This is new breakage, building against 1.5.0beta1 works. You should check two things: Leading zeroes fixups for pkcs#1 and whether there is the pkcs1 flag set in the S-expression used with verify or decrypt. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ametzler at downhill.at.eu.org Sat Jul 2 18:19:57 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 2 Jul 2011 18:19:57 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 In-Reply-To: <20110702112211.GB2013@downhill.g.la> References: <20110702102734.GA2013@downhill.g.la> <20110702112211.GB2013@downhill.g.la> Message-ID: <20110702161957.GD2013@downhill.g.la> On 2011-07-02 Andreas Metzler wrote: > On 2011-07-02 Andreas Metzler wrote: >> ugrading libgcrypt from 1.4.6 to 1.5.0 causes 5 new test suite errors >> in gnutls 2.17.1: > [...] > This is new breakage, building against 1.5.0beta1 works. 2.10.5 also breaks (x509sign-verify x509dn x509self and openpgpself tests) cu andreas -- `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 arfrever.fta at gmail.com Sat Jul 2 17:40:56 2011 From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 2 Jul 2011 17:40:56 +0200 Subject: GnuPG 2.0.17 does not work with Libgcrypt 1.5.0 Message-ID: <201107021740.56821.Arfrever.FTA@gmail.com> The following error occurs when trying to use GnuPG 2.0.17 with Libgcrypt 1.5.0: gpg: pkglue.c:41: mpi_from_sexp: Assertion `data' failed. This problem was not occurring with Libgcrypt 1.5.0 beta1. -- Arfrever Frehtes Taifersar Arahesis -------------- 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 gnupg.org Sat Jul 2 20:12:31 2011 From: wk at gnupg.org (Werner Koch) Date: Sat, 02 Jul 2011 20:12:31 +0200 Subject: GnuPG 2.0.17 does not work with Libgcrypt 1.5.0 In-Reply-To: <201107021740.56821.Arfrever.FTA@gmail.com> (Arfrever Frehtes Taifersar Arahesis's message of "Sat, 2 Jul 2011 17:40:56 +0200") References: <201107021740.56821.Arfrever.FTA@gmail.com> Message-ID: <87mxgweels.fsf@vigenere.g10code.de> On Sat, 2 Jul 2011 17:40, arfrever.fta at gmail.com said: > The following error occurs when trying to use GnuPG 2.0.17 with Libgcrypt 1.5.0: > > gpg: pkglue.c:41: mpi_from_sexp: Assertion `data' failed. Ah right - I forgot about it. There is already a patch in 2.0.17. 2011-06-13 Werner Koch * pkglue.c (mpi_from_sexp, pk_decrypt): Use GCRYMPI_FMT_USG for gcry_sexp_nth_mpi. This fixes a problem with a recent bug fix in Libgcrypt. See commit 13290b0e0fcf3a493e4848b29329d56b69bc4dd9. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ametzler at downhill.at.eu.org Sun Jul 3 09:28:00 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 3 Jul 2011 09:28:00 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 In-Reply-To: <87y60geus6.fsf@vigenere.g10code.de> References: <20110702102734.GA2013@downhill.g.la> <20110702112211.GB2013@downhill.g.la> <87y60geus6.fsf@vigenere.g10code.de> Message-ID: <20110703072800.GA2005@downhill.g.la> On 2011-07-02 Werner Koch wrote: > On Sat, 2 Jul 2011 13:22, ametzler at downhill.at.eu.org said: > > This is new breakage, building against 1.5.0beta1 works. > You should check two things: Leading zeroes fixups for pkcs#1 and > whether there is the pkcs1 flag set in the S-expression used with verify > or decrypt. Good guess. According to git bisect gcrypt commit caf4480811fffdf3b8677864e8d663a68f210e5c causes the issue. cu andreas From wk at gnupg.org Mon Jul 4 09:18:06 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Jul 2011 09:18:06 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 In-Reply-To: <20110703072800.GA2005@downhill.g.la> (Andreas Metzler's message of "Sun, 3 Jul 2011 09:28:00 +0200") References: <20110702102734.GA2013@downhill.g.la> <20110702112211.GB2013@downhill.g.la> <87y60geus6.fsf@vigenere.g10code.de> <20110703072800.GA2005@downhill.g.la> Message-ID: <874o32ecpd.fsf@vigenere.g10code.de> Hi! I see this in gnutls/lib/pk-libgcrypt.c:_wrap_gcry_pk_decrypt bigint_t res; res = gcry_sexp_nth_mpi (s_plain, 0, 0); gcry_sexp_release (s_plain); This is wrong and worked only because of a bug in Libgcrypt < 1.5.0. -- Function: gcry_mpi_t gcry_sexp_nth_mpi (gcry_sexp_t LIST, int NUMBER, int MPIFMT) This function is used to get and convert data from a LIST. This data is assumed to be an MPI stored in the format described by MPIFMT and returned as a standard Libgcrypt MPI. The caller must release this returned value using `gcry_mpi_release'. If there is no data at the given index, the index represents a list or the value can't be converted to an MPI, `NULL' is returned. [added in 1.5:] If you use this function to parse results of a public key function, you most likely want to use `GCRYMPI_FMT_USG'.] If 0 is passed for MPIFMT a default is used, which is and has always been GCRYMPI_FMT_STD. This introduces a leading zero byte so that the integer does not start with the MSB set. Note that some other code uses gcry_sexp_nth_data and is thus not affected by this bug fix. It is the same bug I introduced in GnuPG, thus it is not a surprise that you find it also in gnutls. I did a web search to check the use of this function and found that most projects correctly specified the format they want. I am sorry that I missed to push and update for GnuPG and didn't notified the gnutls hackers. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ametzler at downhill.at.eu.org Mon Jul 4 19:51:46 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 4 Jul 2011 19:51:46 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 In-Reply-To: <874o32ecpd.fsf@vigenere.g10code.de> References: <20110702102734.GA2013@downhill.g.la> <20110702112211.GB2013@downhill.g.la> <87y60geus6.fsf@vigenere.g10code.de> <20110703072800.GA2005@downhill.g.la> <874o32ecpd.fsf@vigenere.g10code.de> Message-ID: <20110704175146.GA3116@downhill.g.la> On 2011-07-04 Werner Koch wrote: > I see this in gnutls/lib/pk-libgcrypt.c:_wrap_gcry_pk_decrypt > bigint_t res; > res = gcry_sexp_nth_mpi (s_plain, 0, 0); > gcry_sexp_release (s_plain); > This is wrong and worked only because of a bug in Libgcrypt < 1.5.0. [...] > If you use this function to parse results of a public key function, > you most likely want to use `GCRYMPI_FMT_USG'.] > If 0 is passed for MPIFMT a default is used, which is and has always > been GCRYMPI_FMT_STD. This introduces a leading zero byte so that the > integer does not start with the MSB set. > Note that some other code uses gcry_sexp_nth_data and is thus not > affected by this bug fix. Hello, thanks. For 2.12.7 [1] and 2.10.5 [2] this fixes one test failure (x509self for 2.12 and x509dn for 2.10) while the other errors remain. Sorry I am not more helpful than that, I am not a programmer. > It is the same bug I introduced in GnuPG, thus it is not a surprise that > you find it also in gnutls. I did a web search to check the use of this > function and found that most projects correctly specified the format > they want. [...] If you were wondering what projects were using gcry_sexp_nth_mpi, here is the list of packages build-depending on libgcrypt11-dev and using the function: gnome-keyring-3.0.3 libotr-3.2.0 openvas-libnasl-2.0.2 gnunet-0.8.1b libspectrum-1.0.0 libgwenhywfar-4.1.0 gnupg2-2.0.17 forked-daapd-0.17 teleport-0.34 libdisplaymigration-0.28 and gnutls. cu andreas [1] --------------- --- gnutls26-2.12.7.orig/lib/gcrypt/pk.c +++ gnutls26-2.12.7/lib/gcrypt/pk.c @@ -202,7 +202,7 @@ _wrap_gcry_pk_decrypt (gnutls_pk_algorit goto cleanup; } - res = gcry_sexp_nth_mpi (s_plain, 0, 0); + res = gcry_sexp_nth_mpi (s_plain, 0, GCRYMPI_FMT_USG); if (res == NULL) { gnutls_assert (); --------------- [2] --------------- --- gnutls26-2.10.5.orig/lib/pk-libgcrypt.c +++ gnutls26-2.10.5/lib/pk-libgcrypt.c @@ -202,7 +202,7 @@ _wrap_gcry_pk_decrypt (gnutls_pk_algorit goto cleanup; } - res = gcry_sexp_nth_mpi (s_plain, 0, 0); + res = gcry_sexp_nth_mpi (s_plain, 0, GCRYMPI_FMT_USG); if (res == NULL) { gnutls_assert (); --------------- From a.radke at arcor.de Fri Jul 8 16:15:52 2011 From: a.radke at arcor.de (Andreas Radke) Date: Fri, 8 Jul 2011 16:15:52 +0200 Subject: libgcrypt 1.5.0 aes-ni test suite fails for i686 Message-ID: <20110708161552.7718d50b@workstation64.home> I'm packaging libgcrypt for ArchLinux. My build system has a core i7 AES capable cpu running x86_64 kernel and userland. The x86_64 package builds fine in our chroot and passes all tests. Building in an i686 chroot gives segfaults in 3 tests. Is this an expected behavior or a bug? Adding --disable-aesni-support makes it pass all tests also for i686. -Andy make check-TESTS make[2]: Entering directory `/build/src/libgcrypt-1.5.0/tests' version:1.5.0: ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia: pubkeys:dsa:elgamal:rsa:ecc: digests:crc:md4:md5:rmd160:sha1:sha256:sha512:tiger:whirlpool: rnd-mod:linux: mpi-asm:i386/mpih-add1.S:i386/mpih-sub1.S:i386/mpih-mul1.S:i386/mpih-mul2.S:i386/mpih-mul3.S:i386/mpih-lshift.S:i386/mpih-rshift.S: hwflist:intel-aesni: fips-mode:n:n: PASS: version PASS: t-mpi-bit PASS: prime PASS: register PASS: ac PASS: ac-schemes PASS: ac-data /bin/sh: line 5: 25392 Segmentation fault ${dir}$tst FAIL: basic PASS: mpitests PASS: tsexp PASS: keygen PASS: pubkey PASS: hmac PASS: keygrip PASS: fips186-dsa /bin/sh: line 5: 25771 Segmentation fault ${dir}$tst FAIL: aeswrap PASS: curves PASS: t-kdf PASS: pkcs1v2 PASS: random MD5 0ms 0ms 20ms 0ms 0ms SHA1 0ms 10ms 20ms 0ms 0ms RIPEMD160 0ms 0ms 20ms 10ms 10ms TIGER192 0ms 0ms 30ms 10ms 10ms SHA256 10ms 10ms 40ms 10ms 10ms SHA384 10ms 30ms 40ms 20ms 10ms SHA512 20ms 20ms 40ms 10ms 10ms SHA224 10ms 10ms 40ms 10ms 10ms MD4 0ms 0ms 30ms 0ms 0ms CRC32 0ms 0ms 10ms 10ms 0ms CRC32RFC1510 0ms 0ms 20ms 0ms 0ms CRC24RFC2440 10ms 10ms 20ms 10ms 10ms WHIRLPOOL 20ms 20ms 30ms 20ms 20ms TIGER 0ms 10ms 30ms 10ms 10ms TIGER2 0ms 0ms 30ms 10ms 10ms ECB/Stream CBC CFB OFB CTR --------------- --------------- --------------- --------------- --------------- 3DES 40ms 40ms 50ms 40ms 40ms 40ms 50ms 40ms 50ms 40ms CAST5 20ms 10ms 20ms 20ms 10ms 20ms 10ms 10ms 20ms 20ms BLOWFISH 10ms 20ms 10ms 20ms 10ms 20ms 10ms 20ms 10ms 10ms AES /bin/sh: line 5: 26083 Segmentation fault ${dir}$tst FAIL: benchmark ======================================== 3 of 21 tests failed Please report to bug-libgcrypt at gnupg.org From steve at stephen-fisher.com Wed Jul 13 18:29:56 2011 From: steve at stephen-fisher.com (Stephen Fisher) Date: Wed, 13 Jul 2011 10:29:56 -0600 Subject: Problem with warning: gcrypt.h '...' is deprecated messages Message-ID: <20110713162956.GA23125@shadow.stephen-fisher.com> Since upgrading to libgcrypt 1.5.0 recently, I'm having problems with messages such as these... /usr/local/include/gcrypt.h:1643: warning: 'gcry_ac_io_t' is deprecated /usr/local/include/gcrypt.h:1649: warning: 'gcry_ac_id_t' is deprecated /usr/local/include/gcrypt.h:1656: warning: 'gcry_ac_id_t' is deprecated The release announcement for 1.5.0 says that using gcry_ac_ functions will produce compile time warnings. We are not using those functions, so the mere inclusion of the gcrypt.h header file is causing these warnings because they are marked with the "_GCRY_ATTR_INTERNAL" macro, which becomes the gcc deprecated attribute. I found this problem with a project I'm a developer for called Wireshark. We compile with -Werror in development versions, so these warnings stop the compilation. Compiling a simple hello world program with gcrypt.h included has the same problem. Defining " _GCRYPT_IN_LIBGCRYPT" to "1" in Wireshark sources before the gcrypt.h inclusion works around this problem in my local sources. From wk at gnupg.org Thu Jul 14 09:53:40 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Jul 2011 09:53:40 +0200 Subject: Problem with warning: gcrypt.h '...' is deprecated messages In-Reply-To: <20110713162956.GA23125@shadow.stephen-fisher.com> (Stephen Fisher's message of "Wed, 13 Jul 2011 10:29:56 -0600") References: <20110713162956.GA23125@shadow.stephen-fisher.com> Message-ID: <87y601z4aj.fsf@vigenere.g10code.de> On Wed, 13 Jul 2011 18:29, steve at stephen-fisher.com said: > /usr/local/include/gcrypt.h:1656: warning: 'gcry_ac_id_t' is deprecated > > The release announcement for 1.5.0 says that using gcry_ac_ functions > will produce compile time warnings. We are not using those functions, That is a bug in some versions of gcc. > with gcrypt.h included has the same problem. Defining " > _GCRYPT_IN_LIBGCRYPT" to "1" in Wireshark sources before the gcrypt.h > inclusion works around this problem in my local sources. Please don't do this. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bradh at frogmouth.net Thu Jul 14 10:54:12 2011 From: bradh at frogmouth.net (Brad Hards) Date: Thu, 14 Jul 2011 18:54:12 +1000 Subject: Problem with warning: gcrypt.h '...' is deprecated messages In-Reply-To: <87y601z4aj.fsf@vigenere.g10code.de> References: <20110713162956.GA23125@shadow.stephen-fisher.com> <87y601z4aj.fsf@vigenere.g10code.de> Message-ID: <201107141854.12205.bradh@frogmouth.net> On Thursday 14 July 2011 17:53:40 Werner Koch wrote: > On Wed, 13 Jul 2011 18:29, steve at stephen-fisher.com said: > > /usr/local/include/gcrypt.h:1656: warning: 'gcry_ac_id_t' is deprecated > > > > The release announcement for 1.5.0 says that using gcry_ac_ functions > > will produce compile time warnings. We are not using those functions, > > That is a bug in some versions of gcc. > > > with gcrypt.h included has the same problem. Defining " > > _GCRYPT_IN_LIBGCRYPT" to "1" in Wireshark sources before the gcrypt.h > > inclusion works around this problem in my local sources. > > Please don't do this. You can work around this problem using gcc pragmas. #pragma GCC diagnostic ignored "-Wdeprecated-declarations" before the include, and #pragma GCC diagnostic warning "-Wdeprecated-declarations" after the include will probably do it. Brad From ametzler at downhill.at.eu.org Sun Jul 24 16:36:02 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 24 Jul 2011 16:36:02 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 In-Reply-To: <20110704175146.GA3116@downhill.g.la> References: <20110702102734.GA2013@downhill.g.la> <20110702112211.GB2013@downhill.g.la> <87y60geus6.fsf@vigenere.g10code.de> <20110703072800.GA2005@downhill.g.la> <874o32ecpd.fsf@vigenere.g10code.de> <20110704175146.GA3116@downhill.g.la> Message-ID: <20110724143601.GB2052@downhill.g.la> On 2011-07-04 Andreas Metzler wrote: > On 2011-07-04 Werner Koch wrote: > > I see this in gnutls/lib/pk-libgcrypt.c:_wrap_gcry_pk_decrypt > > bigint_t res; > > res = gcry_sexp_nth_mpi (s_plain, 0, 0); > > gcry_sexp_release (s_plain); > > This is wrong and worked only because of a bug in Libgcrypt < 1.5.0. > [...] > > If you use this function to parse results of a public key function, > > you most likely want to use `GCRYMPI_FMT_USG'.] [...] > > Note that some other code uses gcry_sexp_nth_data and is thus not > > affected by this bug fix. [...] > For 2.12.7 [1] and 2.10.5 [2] this fixes one test failure > (x509self for 2.12 and x509dn for 2.10) while the other errors remain. > Sorry I am not more helpful than that, I am not a programmer. > [2] > --------------- > --- gnutls26-2.10.5.orig/lib/pk-libgcrypt.c > +++ gnutls26-2.10.5/lib/pk-libgcrypt.c > @@ -202,7 +202,7 @@ _wrap_gcry_pk_decrypt (gnutls_pk_algorit > goto cleanup; > } > - res = gcry_sexp_nth_mpi (s_plain, 0, 0); > + res = gcry_sexp_nth_mpi (s_plain, 0, GCRYMPI_FMT_USG); > if (res == NULL) > { > gnutls_assert (); > --------------- [...] Hello, Well, simply replacing all occurences of gcry_sexp_nth_mpi (..., 0) with gcry_sexp_nth_mpi (..., GCRYMPI_FMT_USG) fixes the testsuite errors of both gnutls 2.10.5 and 2.12.7. The other occurences of gcry_sexp_nth_mpi are all similar to this one: ---------------------------- static int _wrap_gcry_pk_encrypt([...]) [...] gcry_sexp_t s_ciph = NULL, s_data = NULL, s_pkey = NULL; [...] gcry_sexp_t list; [use gcry_sexp_build to fill s_pkey, s_ciph, s_data ] /* pass it to libgcrypt */ rc = gcry_pk_encrypt (&s_ciph, s_data, s_pkey); [...] list = gcry_sexp_find_token (s_ciph, "a", 0); res = gcry_sexp_nth_mpi (list, 1, 0) ---------------------------- Is changing this to "res = gcry_sexp_nth_mpi (list, 1, GCRYMPI_FMT_USG);" the proper fix, or does it just seem to work accidentally? cu andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-2.10.5+gcrypt1.5.patch Type: text/x-diff Size: 4448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-2.12.7+gcrypt1.5.patch Type: text/x-diff Size: 4568 bytes Desc: not available URL: From dbreiser at gmail.com Mon Jul 25 00:33:05 2011 From: dbreiser at gmail.com (David Reiser) Date: Sun, 24 Jul 2011 18:33:05 -0400 Subject: duplicate symbol error while compiling libgcrypt 1.5 Message-ID: I'm trying to build version 1.5 in Mac OS X 10.7 using clang. The build stops with: libtool: link: gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libgcrypt.11.dylib .libs/libgcrypt_la-visibility.o .libs/libgcrypt_la-misc.o .libs/libgcrypt_la-global.o .libs/libgcrypt_la-sexp.o .libs/libgcrypt_la-hwfeatures.o .libs/libgcrypt_la-stdmem.o .libs/libgcrypt_la-secmem.o .libs/libgcrypt_la-missing-string.o .libs/libgcrypt_la-module.o .libs/libgcrypt_la-fips.o .libs/libgcrypt_la-hmac256.o .libs/libgcrypt_la-ath.o .libs/libgcrypt.lax/libcipher.a/ac.o .libs/libgcrypt.lax/libcipher.a/arcfour.o .libs/libgcrypt.lax/libcipher.a/blowfish.o .libs/libgcrypt.lax/libcipher.a/camellia-glue.o .libs/libgcrypt.lax/libcipher.a/camellia.o .libs/libgcrypt.lax/libcipher.a/cast5.o .libs/libgcrypt.lax/libcipher.a/cipher.o .libs/libgcrypt.lax/libcipher.a/crc.o .libs/libgcrypt.lax/libcipher.a/des.o .libs/libgcrypt.lax/libcipher.a/dsa.o .libs/libgcrypt.lax/libcipher.a/ecc.o .libs/libgcrypt.lax/libcipher.a/elgamal.o .libs/libgcrypt.lax/libcipher.a/hash-common.o .libs/libgcrypt.lax/libcipher.a/hmac-tests.o .libs/libgcrypt.lax/libcipher.a/kdf.o .libs/libgcrypt.lax/libcipher.a/md.o .libs/libgcrypt.lax/libcipher.a/md4.o .libs/libgcrypt.lax/libcipher.a/md5.o .libs/libgcrypt.lax/libcipher.a/primegen.o .libs/libgcrypt.lax/libcipher.a/pubkey.o .libs/libgcrypt.lax/libcipher.a/rfc2268.o .libs/libgcrypt.lax/libcipher.a/rijndael.o .libs/libgcrypt.lax/libcipher.a/rmd160.o .libs/libgcrypt.lax/libcipher.a/rsa.o .libs/libgcrypt.lax/libcipher.a/seed.o .libs/libgcrypt.lax/libcipher.a/serpent.o .libs/libgcrypt.lax/libcipher.a/sha1.o .libs/libgcrypt.lax/libcipher.a/sha256.o .libs/libgcrypt.lax/libcipher.a/sha512.o .libs/libgcrypt.lax/libcipher.a/tiger.o .libs/libgcrypt.lax/libcipher.a/twofish.o .libs/libgcrypt.lax/libcipher.a/whirlpool.o .libs/libgcrypt.lax/librandom.a/random-csprng.o .libs/libgcrypt.lax/librandom.a/random-fips.o .libs/libgcrypt.lax/librandom.a/random.o .libs/libgcrypt.lax/librandom.a/rndhw.o .libs/libgcrypt.lax/librandom.a/rndlinux.o .libs/libgcrypt.lax/libmpi.a/ec.o .libs/libgcrypt.lax/libmpi.a/mpi-add.o .libs/libgcrypt.lax/libmpi.a/mpi-bit.o .libs/libgcrypt.lax/libmpi.a/mpi-cmp.o .libs/libgcrypt.lax/libmpi.a/mpi-div.o .libs/libgcrypt.lax/libmpi.a/mpi-gcd.o .libs/libgcrypt.lax/libmpi.a/mpi-inline.o .libs/libgcrypt.lax/libmpi.a/mpi-inv.o .libs/libgcrypt.lax/libmpi.a/mpi-mod.o .libs/libgcrypt.lax/libmpi.a/mpi-mpow.o .libs/libgcrypt.lax/libmpi.a/mpi-mul.o .libs/libgcrypt.lax/libmpi.a/mpi-pow.o .libs/libgcrypt.lax/libmpi.a/mpi-scan.o .libs/libgcrypt.lax/libmpi.a/mpicoder.o .libs/libgcrypt.lax/libmpi.a/mpih-add1.o .libs/libgcrypt.lax/libmpi.a/mpih-div.o .libs/libgcrypt.lax/libmpi.a/mpih-lshift.o .libs/libgcrypt.lax/libmpi.a/mpih-mul.o .libs/libgcrypt.lax/libmpi.a/mpih-mul1.o .libs/libgcrypt.lax/libmpi.a/mpih-mul2.o .libs/libgcrypt.lax/libmpi.a/mpih-mul3.o .libs/libgcrypt.lax/libmpi.a/mpih-rshift.o .libs/libgcrypt.lax/libmpi.a/mpih-sub1.o .libs/libgcrypt.lax/libmpi.a/mpiutil.o .libs/libgcrypt.lax/libcompat.a/compat.o -L/sw/lib /sw/lib/libgpg-error.dylib -install_name /sw/lib/libgcrypt.11.dylib -compatibility_version 19 -current_version 19.0 -Wl,-single_module ld: duplicate symbol __gcry_mpih_add_1 in .libs/libgcrypt.lax/libmpi.a/mpi-add.o and .libs/libgcrypt.lax/libmpi.a/ec.o for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Is this error likely to be specific only to clang? Is there a straightforward solution? Dave -- David Reiser dbreiser at gmail.com From wk at gnupg.org Mon Jul 25 09:22:15 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jul 2011 09:22:15 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 In-Reply-To: <20110724143601.GB2052@downhill.g.la> (Andreas Metzler's message of "Sun, 24 Jul 2011 16:36:02 +0200") References: <20110702102734.GA2013@downhill.g.la> <20110702112211.GB2013@downhill.g.la> <87y60geus6.fsf@vigenere.g10code.de> <20110703072800.GA2005@downhill.g.la> <874o32ecpd.fsf@vigenere.g10code.de> <20110704175146.GA3116@downhill.g.la> <20110724143601.GB2052@downhill.g.la> Message-ID: <87ipqqsu3c.fsf@vigenere.g10code.de> On Sun, 24 Jul 2011 16:36, ametzler at downhill.at.eu.org said: > Is changing this to "res = gcry_sexp_nth_mpi (list, 1, GCRYMPI_FMT_USG);" > the proper fix, or does it just seem to work accidentally? I am pretty sure that this is correct. The bug was probably introduced by copying code from GnuPG which had the same error. It is quite possible that I once proposed to do it this way :-). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tmraz at redhat.com Mon Jul 25 09:41:44 2011 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 25 Jul 2011 09:41:44 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 In-Reply-To: <87ipqqsu3c.fsf@vigenere.g10code.de> References: <20110702102734.GA2013@downhill.g.la> <20110702112211.GB2013@downhill.g.la> <87y60geus6.fsf@vigenere.g10code.de> <20110703072800.GA2005@downhill.g.la> <874o32ecpd.fsf@vigenere.g10code.de> <20110704175146.GA3116@downhill.g.la> <20110724143601.GB2052@downhill.g.la> <87ipqqsu3c.fsf@vigenere.g10code.de> Message-ID: <1311579704.6273.49.camel@vespa.frost.loc> On Mon, 2011-07-25 at 09:22 +0200, Werner Koch wrote: > On Sun, 24 Jul 2011 16:36, ametzler at downhill.at.eu.org said: > > > Is changing this to "res = gcry_sexp_nth_mpi (list, 1, GCRYMPI_FMT_USG);" > > the proper fix, or does it just seem to work accidentally? > > I am pretty sure that this is correct. The bug was probably introduced > by copying code from GnuPG which had the same error. It is quite > possible that I once proposed to do it this way :-). Hmm... wouldn't it be more proper to make the default MPI format for gcry_sexp_nth_mpi USG? Given the libgcrypt-1.4.x always behaved like this this is strictly said API/ABI break, regardless of what documentation says. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From wk at gnupg.org Mon Jul 25 12:39:12 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jul 2011 12:39:12 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 In-Reply-To: <1311579704.6273.49.camel@vespa.frost.loc> (Tomas Mraz's message of "Mon, 25 Jul 2011 09:41:44 +0200") References: <20110702102734.GA2013@downhill.g.la> <20110702112211.GB2013@downhill.g.la> <87y60geus6.fsf@vigenere.g10code.de> <20110703072800.GA2005@downhill.g.la> <874o32ecpd.fsf@vigenere.g10code.de> <20110704175146.GA3116@downhill.g.la> <20110724143601.GB2052@downhill.g.la> <87ipqqsu3c.fsf@vigenere.g10code.de> <1311579704.6273.49.camel@vespa.frost.loc> Message-ID: <87ei1eskz3.fsf@vigenere.g10code.de> On Mon, 25 Jul 2011 09:41, tmraz at redhat.com said: > Hmm... wouldn't it be more proper to make the default MPI format for > gcry_sexp_nth_mpi USG? Given the libgcrypt-1.4.x always behaved like > this this is strictly said API/ABI break, regardless of what > documentation says. No, it didn't behaved like this. The case with the leading zeroes is more complex that just the GCRMPI_FMT_STD default. It was a bug in GnuPG to use the default. Fortunately most users of Libgcrypt didn't copied that bug. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tmraz at redhat.com Mon Jul 25 12:51:39 2011 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 25 Jul 2011 12:51:39 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 In-Reply-To: <87ei1eskz3.fsf@vigenere.g10code.de> References: <20110702102734.GA2013@downhill.g.la> <20110702112211.GB2013@downhill.g.la> <87y60geus6.fsf@vigenere.g10code.de> <20110703072800.GA2005@downhill.g.la> <874o32ecpd.fsf@vigenere.g10code.de> <20110704175146.GA3116@downhill.g.la> <20110724143601.GB2052@downhill.g.la> <87ipqqsu3c.fsf@vigenere.g10code.de> <1311579704.6273.49.camel@vespa.frost.loc> <87ei1eskz3.fsf@vigenere.g10code.de> Message-ID: <1311591099.6273.52.camel@vespa.frost.loc> On Mon, 2011-07-25 at 12:39 +0200, Werner Koch wrote: > On Mon, 25 Jul 2011 09:41, tmraz at redhat.com said: > > > Hmm... wouldn't it be more proper to make the default MPI format for > > gcry_sexp_nth_mpi USG? Given the libgcrypt-1.4.x always behaved like > > this this is strictly said API/ABI break, regardless of what > > documentation says. > > No, it didn't behaved like this. The case with the leading zeroes is > more complex that just the GCRMPI_FMT_STD default. It was a bug in > GnuPG to use the default. Fortunately most users of Libgcrypt didn't > copied that bug. I understand that, but what would be broken (that was not broken already in libgcrypt-1.4.x) if the GCRY_MPI_FMT_USG was declared as default for gcry_sexp_nth_mpi() ? Is there currently any known use in existing software that expects the GCRY_MPI_FMT_STD if 0 is specified as format in gcry_sexp_nth_mpi()? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From wk at gnupg.org Mon Jul 25 13:30:50 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jul 2011 13:30:50 +0200 Subject: new testsuite errors with gcrypt 1.5 and gnutls 2.17.1 In-Reply-To: <1311591099.6273.52.camel@vespa.frost.loc> (Tomas Mraz's message of "Mon, 25 Jul 2011 12:51:39 +0200") References: <20110702102734.GA2013@downhill.g.la> <20110702112211.GB2013@downhill.g.la> <87y60geus6.fsf@vigenere.g10code.de> <20110703072800.GA2005@downhill.g.la> <874o32ecpd.fsf@vigenere.g10code.de> <20110704175146.GA3116@downhill.g.la> <20110724143601.GB2052@downhill.g.la> <87ipqqsu3c.fsf@vigenere.g10code.de> <1311579704.6273.49.camel@vespa.frost.loc> <87ei1eskz3.fsf@vigenere.g10code.de> <1311591099.6273.52.camel@vespa.frost.loc> Message-ID: <87aac2sil1.fsf@vigenere.g10code.de> On Mon, 25 Jul 2011 12:51, tmraz at redhat.com said: > gcry_sexp_nth_mpi() ? Is there currently any known use in existing > software that expects the GCRY_MPI_FMT_STD if 0 is specified as format > in gcry_sexp_nth_mpi()? We can't know for sure. Libgcrypt is also used by proprietary applications and thus we have no way to check it. Before I released 1.5.0 I did a web search and found some code using Libgcrypt. Except for GnuPG and GNUTLS they all seemed to do it right. Unfortunately I forgot to notify the GNUTLS maintainers. I even pondered with a system wide Libgcrypt option to change the default so that in case of a problem this could be easily fixed. However that might be worse than just fixing the applications right away. It is clearly a bug but Libgcrypt and I prefer to fix bugs than to maintain bug emulation code for all eternity. There will be a GnuPG 2.0.18 shortly just to address this problem. I have not heard about other projects suffering from that bug. gold(1) seems to be a more severe problem than this bug fix. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.