From dennis at ausil.us Sat May 1 15:10:26 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Sat May 1 15:08:20 2004 Subject: building newpg Message-ID: <200405012310.26931.dennis@ausil.us> Hi ot sure if this is the right list or not but im trying to build newpg against libgcrypt-1.1.94 and am comming across the following errors. cc -DHAVE_CONFIG_H -I. -I. -I.. -O2 -g -pipe -march=i386 -mcpu=i686 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c `test -f 'maperror.c' || echo './'`maperror.c maperror.c: In function `map_gcry_err': maperror.c:72: error: `GCRYERR_EOF' undeclared (first use in this function) maperror.c:72: error: (Each undeclared identifier is reported only once maperror.c:72: error: for each function it appears in.) maperror.c:80: error: `GCRYERR_WRONG_PK_ALGO' undeclared (first use in this function) maperror.c:81: error: `GCRYERR_INV_PK_ALGO' undeclared (first use in this function) maperror.c:82: error: `GCRYERR_INV_MD_ALGO' undeclared (first use in this function) maperror.c:83: error: `GCRYERR_INV_CIPHER_ALGO' undeclared (first use in this function) maperror.c:86: error: `GCRYERR_INV_KEYLEN' undeclared (first use in this function) maperror.c:87: error: `GCRYERR_WEAK_KEY' undeclared (first use in this function) maperror.c:88: error: `GCRYERR_BAD_PUBLIC_KEY' undeclared (first use in this function) maperror.c:89: error: `GCRYERR_BAD_SECRET_KEY' undeclared (first use in this function) maperror.c:90: error: `GCRYERR_BAD_SIGNATURE' undeclared (first use in this function) maperror.c:92: error: `GCRYERR_BAD_MPI' undeclared (first use in this function) maperror.c:96: error: `GCRYERR_INV_ARG' undeclared (first use in this function) maperror.c:97: error: `GCRYERR_INV_OP' undeclared (first use in this function) maperror.c:98: error: `GCRYERR_INTERNAL' undeclared (first use in this function) maperror.c:99: error: `GCRYERR_INV_CIPHER_MODE' undeclared (first use in this function) maperror.c:103: error: `GCRYERR_SELFTEST' undeclared (first use in this function) maperror.c:107: error: `GCRYERR_SEXP_INV_LEN_SPEC' undeclared (first use in this function) maperror.c:108: error: `GCRYERR_SEXP_STRING_TOO_LONG' undeclared (first use in this function) maperror.c:109: error: `GCRYERR_SEXP_UNMATCHED_PAREN' undeclared (first use in this function) maperror.c:110: error: `GCRYERR_SEXP_NOT_CANONICAL' undeclared (first use in this function) maperror.c:111: error: `GCRYERR_SEXP_BAD_CHARACTER' undeclared (first use in this function) maperror.c:112: error: `GCRYERR_SEXP_BAD_QUOTATION' undeclared (first use in this function) maperror.c:113: error: `GCRYERR_SEXP_ZERO_PREFIX' undeclared (first use in this function) maperror.c:114: error: `GCRYERR_SEXP_NESTED_DH' undeclared (first use in this function) maperror.c:115: error: `GCRYERR_SEXP_UNMATCHED_DH' undeclared (first use in this function) maperror.c:116: error: `GCRYERR_SEXP_UNEXPECTED_PUNC' undeclared (first use in this function) maperror.c:117: error: `GCRYERR_SEXP_BAD_HEX_CHAR' undeclared (first use in this function) maperror.c:118: error: `GCRYERR_SEXP_ODD_HEX_NUMBERS' undeclared (first use in this function) maperror.c:119: error: `GCRYERR_SEXP_BAD_OCT_CHAR' undeclared (first use in this function) maperror.c:123: error: `GCRYERR_NO_MEM' undeclared (first use in this function) maperror.c:125: error: `GCRYERR_NOT_IMPL' undeclared (first use in this function) maperror.c:126: error: `GCRYERR_CONFLICT' undeclared (first use in this function) maperror.c:128: error: `GCRYERR_INV_OBJ' undeclared (first use in this function) maperror.c:129: error: `GCRYERR_TOO_SHORT' undeclared (first use in this function) maperror.c:130: error: `GCRYERR_TOO_LARGE' undeclared (first use in this function) maperror.c:131: error: `GCRYERR_NO_OBJ' undeclared (first use in this function) make[3]: *** [maperror.o] Error 1 make[3]: Leaving directory `/var/tmp/rpm/newpg-0.9.4/common' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/rpm/newpg-0.9.4/common' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/rpm/newpg-0.9.4' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm/rpm-tmp.84339 (%build) RPM build errors: Bad exit status from /var/tmp/rpm/rpm-tmp.84339 (%build) all was fine until getting to this version of gcrypt has the api changed? Dennis From wk at gnupg.org Sat May 1 17:23:07 2004 From: wk at gnupg.org (Werner Koch) Date: Sat May 1 17:05:39 2004 Subject: building newpg In-Reply-To: <200405012310.26931.dennis@ausil.us> (Dennis Gilmore's message of "Sat, 1 May 2004 23:10:26 +1000") References: <200405012310.26931.dennis@ausil.us> Message-ID: <8765bg8944.fsf@vigenere.g10code.de> On Sat, 1 May 2004 23:10:26 +1000, Dennis Gilmore said: > Hi ot sure if this is the right list or not but im trying to build newpg > against libgcrypt-1.1.94 and am comming across the following errors. Don't build newpg at all. It has been superseded by gnupg-1.9.x . You would need an old libgcrypt < 1.1.42 to build it. The configure sscript was not able to detect newer versions with a changed API. Werner From dennis at ausil.us Sun May 2 02:39:41 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Sun May 2 02:37:24 2004 Subject: building newpg In-Reply-To: <8765bg8944.fsf@vigenere.g10code.de> References: <200405012310.26931.dennis@ausil.us> <8765bg8944.fsf@vigenere.g10code.de> Message-ID: <200405021039.41738.dennis@ausil.us> Once upon a time Sunday 02 May 2004 1:23 am, Werner Koch wrote: > Don't build newpg at all. ?It has been superseded by gnupg-1.9.x . > > You would need an old libgcrypt < 1.1.42 to build it. ?The configure > sscript was not able to detect newer versions with a changed API. hmm ok this seems just wrong there is no gnupg-1.9.x the development tree is at 1.3.5 but why would a stable peice of software require an unstable one to work. shouldn't libgcrpt still provide the nessecary API until the stable version of gnupg has the neccessary functionality? Dennis From mo at g10code.com Sun May 2 17:19:44 2004 From: mo at g10code.com (Moritz Schulte) Date: Sun May 2 17:22:55 2004 Subject: building newpg In-Reply-To: <200405021039.41738.dennis@ausil.us> (Dennis Gilmore's message of "Sun, 2 May 2004 10:39:41 +1000") References: <200405012310.26931.dennis@ausil.us> <8765bg8944.fsf@vigenere.g10code.de> <200405021039.41738.dennis@ausil.us> Message-ID: Dennis Gilmore writes: > hmm ok this seems just wrong there is no gnupg-1.9.x There is. See http://www.gnupg.org/(en)/download/cvs_access.html; GnuPG 1.9 can be accessed by checking out the "GNUPG-1-9" branch of the "gnupg" module. Your checkout command should be similar to: cvs -z 9 -d :pserver:anoncvs@cvs.gnupg.org:/cvs/gnupg co -r GNUPG-1-9-BRANCH -d gnupg-1-9 gnupg > the development tree is at 1.3.5 This is not the only development tree. 1.3.5 is much closer to 1.2 than 1.9 is. > but why would a stable peice of software require an unstable one to > work. I don't understand. Neither GnuPG 1.9/1.3.5 nor "NewPG" nor Libgcrypt < 1.2 has been declared as "stable". moritz -- Moritz Schulte CF0508EC/2E18 1822 1468 11F7 4BDF 2A75 1276 2417 CF05 08EC From christian at grothoff.org Tue May 4 06:52:52 2004 From: christian at grothoff.org (Christian Grothoff) Date: Wed May 5 16:29:35 2004 Subject: Gratuitous gcry_fast_random_poll (Was: Re: [GNUnet-developers] _gcry_ath_mutex_lock) In-Reply-To: <200405031820.54272.christian@grothoff.org> References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405031820.54272.christian@grothoff.org> Message-ID: <200405032352.52343.christian@grothoff.org> [Also to gcrypt-devel since I believe this is partially libgcrypt's fault] I figured it out. While the way that we're using libgcrypt should not require any synchronization for this code, the code does in gcry_cipher_open the completely gratuitous /* If the application missed to call the random poll function, we do it here to ensure that it is used once in a while. */ _gcry_fast_random_poll (); Now, while creating a symcipher and doing some encryption with it should not require locking, the random_poll operation does require locking. Now, GNUnet does not do any locking here (since we assumed that no locking would be required) -- which results in the assertion failure you describe below (given concurrent use). Now, we can fix it by doing more (useless) locking in GNUnet (will patch), but I'll CC this to libgcrypt-devel since I believe they should avoid doing such calls that require locks on paths that one would commonly not consider accessing the random-pool or other global datastructures. > On Monday 03 May 2004 08:05, Glenn McGrath wrote: > > Ive uploaded debian packages of 0.6.2, however ive just realised i have > > a problem with it, i get the following error. > > > > gnunetd: ath.c:181: _gcry_ath_mutex_lock: Assertion `*lock == > > ((ath_mutex_t) 0)' failed. > > > > I built the deb against libgcrypt-1.2.0, to doso i copied the files > > src/util/hostkey_gcrypt.c and src/util/symcipher_gcrypt.c from cvs. > > > > The gcrypt function in question is ath_mutex_lock(), it tried tracking > > it down using gdb but had no luck. From wk at gnupg.org Wed May 5 19:35:53 2004 From: wk at gnupg.org (Werner Koch) Date: Wed May 5 19:20:25 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <200405032352.52343.christian@grothoff.org> (Christian Grothoff's message of "Mon, 3 May 2004 23:52:52 -0500") References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405031820.54272.christian@grothoff.org> <200405032352.52343.christian@grothoff.org> Message-ID: <87hduuwzd2.fsf@vigenere.g10code.de> On Mon, 3 May 2004 23:52:52 -0500, Christian Grothoff said: > concurrent use). Now, we can fix it by doing more (useless) locking in > GNUnet (will patch), but I'll CC this to libgcrypt-devel since I believe they > should avoid doing such calls that require locks on paths that one would > commonly not consider accessing the random-pool or other global > datastructures. This call to fast_random_poll() is there on purpose as the comment describes. Without that people will very likely forget to add a couple of poll clals and we better make sure that they are at least used from time to time. I don't know what you mean by locking though. If you are using a multi-threaded application you need to make sure that libgcrypt is porperly initialized - see the section in the manual. >> > gnunetd: ath.c:181: _gcry_ath_mutex_lock: Assertion `*lock == >> > ((ath_mutex_t) 0)' failed. May it be that another library you link to uses pthreads and you don't know about this. libpcsclite for example does this. Werner From marcus.brinkmann at ruhr-uni-bochum.de Wed May 5 19:35:34 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed May 5 19:42:33 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <87hduuwzd2.fsf@vigenere.g10code.de> References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405031820.54272.christian@grothoff.org> <200405032352.52343.christian@grothoff.org> <87hduuwzd2.fsf@vigenere.g10code.de> Message-ID: <87n04mg4k9.wl@ulysses.g10code.de> At Wed, 05 May 2004 19:35:53 +0200, Werner Koch wrote: > I don't know what you mean by locking though. If you are using a > multi-threaded application you need to make sure that libgcrypt is > porperly initialized - see the section in the manual. The asserts in the code check if the proper lock/unlock calls are made in the single-threaded case, too. I put them in there for my own debugging at the time - in GPGME, where the code originated, all locking happens internally, so an assertion would show if internal to GPGME some locks were inproperly used. If the locking interface is exported in gcrypt, and users are responsible for their own locking, these assertions should probably be removed. Thanks, Marcus From wk at gnupg.org Wed May 5 20:36:09 2004 From: wk at gnupg.org (Werner Koch) Date: Wed May 5 20:20:27 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <87n04mg4k9.wl@ulysses.g10code.de> (Marcus Brinkmann's message of "Wed, 05 May 2004 19:35:34 +0200") References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405031820.54272.christian@grothoff.org> <200405032352.52343.christian@grothoff.org> <87hduuwzd2.fsf@vigenere.g10code.de> <87n04mg4k9.wl@ulysses.g10code.de> Message-ID: <87fzaevi06.fsf@vigenere.g10code.de> On Wed, 05 May 2004 19:35:34 +0200, Marcus Brinkmann said: > The asserts in the code check if the proper lock/unlock calls are made > in the single-threaded case, too. Which is a Good Thing. > If the locking interface is exported in gcrypt, and users are > responsible for their own locking, these assertions should probably be > removed. Why? Calling ath_mutex_lock on a locked mutex is a severe error in any case. Werner From fw at deneb.enyo.de Wed May 5 20:57:37 2004 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed May 5 20:54:47 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <87hduuwzd2.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 05 May 2004 19:35:53 +0200") References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405031820.54272.christian@grothoff.org> <200405032352.52343.christian@grothoff.org> <87hduuwzd2.fsf@vigenere.g10code.de> Message-ID: <87fzaeaehq.fsf@deneb.enyo.de> * Werner Koch: > This call to fast_random_poll() is there on purpose as the comment > describes. Without that people will very likely forget to add a > couple of poll clals and we better make sure that they are at least > used from time to time. Sorry, those people won't be able to write decent crypto software anyway. 8-/ Maybe it's better to check that the appropriate minimum number of calls is being made and abort() if necessary. Some fast_random_poll() call in GnuPG is also a bottleneck during signature verification. (I think I've already reported that.) -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, di-ve.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com. From marcus.brinkmann at ruhr-uni-bochum.de Wed May 5 21:13:11 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed May 5 21:17:06 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <87fzaevi06.fsf@vigenere.g10code.de> References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405031820.54272.christian@grothoff.org> <200405032352.52343.christian@grothoff.org> <87hduuwzd2.fsf@vigenere.g10code.de> <87n04mg4k9.wl@ulysses.g10code.de> <87fzaevi06.fsf@vigenere.g10code.de> Message-ID: <87k6zqg01k.wl@ulysses.g10code.de> At Wed, 05 May 2004 20:36:09 +0200, Werner Koch wrote: > > On Wed, 05 May 2004 19:35:34 +0200, Marcus Brinkmann said: > > > The asserts in the code check if the proper lock/unlock calls are made > > in the single-threaded case, too. > > Which is a Good Thing. > > > If the locking interface is exported in gcrypt, and users are > > responsible for their own locking, these assertions should probably be > > removed. > > Why? Calling ath_mutex_lock on a locked mutex is a severe error in > any case. Yes, but compare it with pthread: you have error checking locks (robust locks) and fast locks. And everybody just uses the fast locks and never checks the error. It's not a good thing if a library gives an assertion failure, unless there really is an internal error. An error value returned would be better, but nobody would check it. Oh well. Marcus From nmav at gnutls.org Wed May 5 22:21:56 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed May 5 22:15:14 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <87fzaeaehq.fsf@deneb.enyo.de> References: <20040503230547.290bdeed.bug1@iinet.net.au> <87hduuwzd2.fsf@vigenere.g10code.de> <87fzaeaehq.fsf@deneb.enyo.de> Message-ID: <200405052321.56407.nmav@gnutls.org> On Wednesday 05 May 2004 21:57, Florian Weimer wrote: > > This call to fast_random_poll() is there on purpose as the comment > > describes. Without that people will very likely forget to add a > > couple of poll clals and we better make sure that they are at least > > used from time to time. > Sorry, those people won't be able to write decent crypto software > anyway. 8-/ Maybe it's better to check that the appropriate minimum > number of calls is being made and abort() if necessary. Well since this function is neither documented nor exported, you shouldn't expect anyone to call it. An exported random pool initialization function would help here. -- Nikos Mavroyanopoulos From grothoff at cs.purdue.edu Wed May 5 23:10:09 2004 From: grothoff at cs.purdue.edu (Christian Grothoff) Date: Wed May 5 23:07:49 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <87hduuwzd2.fsf@vigenere.g10code.de> References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405032352.52343.christian@grothoff.org> <87hduuwzd2.fsf@vigenere.g10code.de> Message-ID: <200405051610.09219.grothoff@cs.purdue.edu> On Wednesday 05 May 2004 12:35, Werner Koch wrote: > On Mon, 3 May 2004 23:52:52 -0500, Christian Grothoff said: > > concurrent use). Now, we can fix it by doing more (useless) locking in > > GNUnet (will patch), but I'll CC this to libgcrypt-devel since I believe > > they should avoid doing such calls that require locks on paths that one > > would commonly not consider accessing the random-pool or other global > > datastructures. > > This call to fast_random_poll() is there on purpose as the comment > describes. Without that people will very likely forget to add a > couple of poll clals and we better make sure that they are at least > used from time to time. All I'm saying is leave that to the application. For example, I may not be using any key generation from libgcrypt, so I definitely don't need any of the PRNG code. And as others have remarked before, assertion failures are bad anyway -- return error codes. If the client doesn't check them, then the software is probably not worth worrying about anyway. > I don't know what you mean by locking though. If you are using a > multi-threaded application you need to make sure that libgcrypt is > porperly initialized - see the section in the manual. I'm aware of that discussion. The problem is that the code in question was originally written for an earlier version of libgcrypt and had not been adapted. Anyway, it should work just fine (with any version of libgcrypt) if the client guarantees that only one thread enters libgcrypt at a time. Now, that's a bit strong and could be relaxed to "one thread enters libgcrypt at a time for operations that may require global state" -- and the call in question requires global state (and sync) on a path where that's completely counter-intuitive. > >> > gnunetd: ath.c:181: _gcry_ath_mutex_lock: Assertion `*lock == > >> > ((ath_mutex_t) 0)' failed. > > May it be that another library you link to uses pthreads and you don't > know about this. libpcsclite for example does this. Oh, we're using pthreads, I've resolved the problem by putting some extra locks around our libgcrypt calls (since I don't want to rely on a 'recent' libgcrypt version). Nevertheless I find the random-poll is completely out of place. It would take 2 lines of code for me to call it every n seconds or something like that, which would be much more appropriate than this kind of random (pun not intended) injection of the call. The code in question initializes the symcipher millions of times but never ever creates a single random key. Ideally, it would never even open /dev/random. Christian From wk at gnupg.org Fri May 7 11:01:27 2004 From: wk at gnupg.org (Werner Koch) Date: Fri May 7 10:45:30 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <87k6zqg01k.wl@ulysses.g10code.de> (Marcus Brinkmann's message of "Wed, 05 May 2004 21:13:11 +0200") References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405031820.54272.christian@grothoff.org> <200405032352.52343.christian@grothoff.org> <87hduuwzd2.fsf@vigenere.g10code.de> <87n04mg4k9.wl@ulysses.g10code.de> <87fzaevi06.fsf@vigenere.g10code.de> <87k6zqg01k.wl@ulysses.g10code.de> Message-ID: <87brl0txug.fsf@vigenere.g10code.de> On Wed, 05 May 2004 21:13:11 +0200, Marcus Brinkmann said: > Yes, but compare it with pthread: you have error checking locks > (robust locks) and fast locks. And everybody just uses the fast locks > and never checks the error. Which is bad because you won't detect logical errors in your program. > It's not a good thing if a library gives an assertion failure, unless > there really is an internal error. An error value returned would be It is an internal error. The library is used in a non-allowed way and all shit may happen later. Be glad that it tells you that - even if you don't want so. It is not different from free(3) which might abort the process if it detects an invalid state of the heaps. Werner From wk at gnupg.org Fri May 7 11:03:48 2004 From: wk at gnupg.org (Werner Koch) Date: Fri May 7 10:45:40 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <87fzaeaehq.fsf@deneb.enyo.de> (Florian Weimer's message of "Wed, 05 May 2004 20:57:37 +0200") References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405031820.54272.christian@grothoff.org> <200405032352.52343.christian@grothoff.org> <87hduuwzd2.fsf@vigenere.g10code.de> <87fzaeaehq.fsf@deneb.enyo.de> Message-ID: <877jvotxqj.fsf@vigenere.g10code.de> On Wed, 05 May 2004 20:57:37 +0200, Florian Weimer said: > Sorry, those people won't be able to write decent crypto software > anyway. 8-/ Maybe it's better to check that the appropriate minimum > number of calls is being made and abort() if necessary. As of now there is no published API do do this polling, so we need to rely on the internal hacks. > Some fast_random_poll() call in GnuPG is also a bottleneck during > signature verification. (I think I've already reported that.) Yes, I know. Werner From wk at gnupg.org Fri May 7 11:06:07 2004 From: wk at gnupg.org (Werner Koch) Date: Fri May 7 10:50:21 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <200405052321.56407.nmav@gnutls.org> (Nikos Mavroyanopoulos's message of "Wed, 05 May 2004 23:21:56 +0300") References: <20040503230547.290bdeed.bug1@iinet.net.au> <87hduuwzd2.fsf@vigenere.g10code.de> <87fzaeaehq.fsf@deneb.enyo.de> <200405052321.56407.nmav@gnutls.org> Message-ID: <873c6ctxmo.fsf@vigenere.g10code.de> On Wed, 05 May 2004 23:21:56 +0300, Nikos Mavroyanopoulos said: > expect anyone to call it. An exported random pool initialization function > would help here. Its not about initializing the RNG but to update the internal pool of the RNG from time to time. Doing this in the cipher and md open calls seesm to be a good place and we are doing so for many years. Ciao, Werner From wk at gnupg.org Fri May 7 11:17:11 2004 From: wk at gnupg.org (Werner Koch) Date: Fri May 7 11:00:25 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <200405051610.09219.grothoff@cs.purdue.edu> (Christian Grothoff's message of "Wed, 5 May 2004 16:10:09 -0500") References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405032352.52343.christian@grothoff.org> <87hduuwzd2.fsf@vigenere.g10code.de> <200405051610.09219.grothoff@cs.purdue.edu> Message-ID: <87y8o4sijs.fsf@vigenere.g10code.de> On Wed, 5 May 2004 16:10:09 -0500, Christian Grothoff said: > All I'm saying is leave that to the application. For example, I may not be > using any key generation from libgcrypt, so I definitely don't need any of You may want to create a signature and thus you need random. There are quite some palces where random numbers are required and so for the avaerage application the current scheme works. > the PRNG code. And as others have remarked before, assertion failures are > bad anyway -- return error codes. If the client doesn't check them, then the It is not always pissible to return error codes. Some functions are expected to simply work. If they don;t, something is badly wrong with their environment. > originally written for an earlier version of libgcrypt and had not been > adapted. Anyway, it should work just fine (with any version of libgcrypt) if > the client guarantees that only one thread enters libgcrypt at a time. Now, Obviously there is another thread using libgcrypt. > time for operations that may require global state" -- and the call in > question requires global state (and sync) on a path where that's completely > counter-intuitive. You should not make any assumption about the internal working of a library. This may work for one version but maybe not for the next. We have tried to hide all details but your are still looking inside.\ - don't do this. > Oh, we're using pthreads, I've resolved the problem by putting some extra > locks around our libgcrypt calls (since I don't want to rely on a 'recent' > libgcrypt version). Nevertheless I find the random-poll is completely out of There is only one stable release yet - all prior releases where clearly marked as under development. Please change gnunet to properly intialize libgcrypt and you are set. > random (pun not intended) injection of the call. The code in question > initializes the symcipher millions of times but never ever creates a single If you make such heavy use of cipher_open, please change your application to presever the context returned by cipher_open and use gcry_cipher_reset before setting up a new key and IV. This will avoid a lot of other overhead too. Werner From wk at gnupg.org Fri May 7 16:14:09 2004 From: wk at gnupg.org (Werner Koch) Date: Fri May 7 15:55:22 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <200405071319.16518.nmav@gnutls.org> (Nikos Mavroyanopoulos's message of "Fri, 07 May 2004 13:19:16 +0300") References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405052321.56407.nmav@gnutls.org> <873c6ctxmo.fsf@vigenere.g10code.de> <200405071319.16518.nmav@gnutls.org> Message-ID: <87hdusqq8e.fsf@vigenere.g10code.de> [I assume, Nikos sent his mail accidently only to me]. On Fri, 07 May 2004 13:19:16 +0300, Nikos Mavroyanopoulos said: > Seems fine then. Maybe removing the initialization part of this function > might speed up things to programs that do not use the rnd (just hash > or encrypt). So this will only update the pool if initialized. I don't know if I have done these changes right now in the CVS and you or Christan might want to look at it. If this works out, I will gop into 1.2.1. The random number is now only initialzed when random numbers are actually been requested or the new macro gcry_fast_random_poll() has been used. The internal _gcry_fast_random_poll is a NOP as long as the RNG has not been initialized - thus for simple application /dev/random should not even be opened. There is of course the drawback that we put less of possible entropy into the pool but I don't consider this a serious problem because two calls to the internal fast random poll function in a short time won't make any difference as the current time and used resources will be mostly identical (I assume that a cipher_open or md_open will immediatley be followed by a request for random or vice versa). And more important, good random for the RNG will either be sucked in from /dev/random or a seed file at startup anyway. If you have an application with a main processing loop or other points in the code which are regulary called (say about every second) you might already want to start adding this #ifdef gcry_fast_random_poll gcry_fast_random_poll (); #endif and as soon as you use compile against a newer libgcrypt version this will be used. Don't use this in a timer tick handler - it would be mostly pointless. Salam-Shalom, Werner From nmav at gnutls.org Sat May 8 10:09:59 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sat May 8 10:03:09 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <87hdusqq8e.fsf@vigenere.g10code.de> References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405071319.16518.nmav@gnutls.org> <87hdusqq8e.fsf@vigenere.g10code.de> Message-ID: <200405081109.59337.nmav@gnutls.org> On Friday 07 May 2004 17:14, Werner Koch wrote: > > Seems fine then. Maybe removing the initialization part of this function > > might speed up things to programs that do not use the rnd (just hash > > or encrypt). So this will only update the pool if initialized. I don't > > know if > I have done these changes right now in the CVS and you or Christan > might want to look at it. If this works out, I will gop into 1.2.1. > The random number is now only initialzed when random numbers are > actually been requested or the new macro gcry_fast_random_poll() has > been used. The internal _gcry_fast_random_poll is a NOP as long as > the RNG has not been initialized - thus for simple application > /dev/random should not even be opened. I was just wondering how many times is /dev/random accessed? I though that it opened only once in the initialization of the random pool. I ask because I came across a server the used fork for each client and initializes libgcrypt (and gnutls) on every child. If /dev/random is accessed several times from each child then /dev/random would be exhausted soon, thus the server's childs would be blocked (gnutls calls several times the md_open, cipher_open as well as the random functions). > Salam-Shalom, > Werner -- Nikos Mavroyanopoulos From wk at gnupg.org Sun May 9 09:55:18 2004 From: wk at gnupg.org (Werner Koch) Date: Sun May 9 09:40:15 2004 Subject: Gratuitous gcry_fast_random_poll In-Reply-To: <200405081109.59337.nmav@gnutls.org> (Nikos Mavroyanopoulos's message of "Sat, 08 May 2004 11:09:59 +0300") References: <20040503230547.290bdeed.bug1@iinet.net.au> <200405071319.16518.nmav@gnutls.org> <87hdusqq8e.fsf@vigenere.g10code.de> <200405081109.59337.nmav@gnutls.org> Message-ID: <87ekpunift.fsf@vigenere.g10code.de> On Sat, 08 May 2004 11:09:59 +0300, Nikos Mavroyanopoulos said: > I was just wondering how many times is /dev/random accessed? I > though that it opened only once in the initialization of the > random pool. I ask because I came across a server the used fork Exactly. The random pool will be filled up and unless you have a seed file this will use /dev/random. A fork will reuse the same pool but due to the two stage mixing the random won't match. Werner From nmav at gnutls.org Wed May 12 11:11:44 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed May 12 11:04:41 2004 Subject: concerning libgpg-error Message-ID: <200405121211.44973.nmav@gnutls.org> Hello, I bring again the libgpg-error issue. Would it be possible to add the required functions for libgcrypt (without gettext and the extra stuff), in a single object which will be compiled if libgpg-error is not found in the system[0]? This would make the library much easier to install, and avoid a library dependence. [0]. a warning may be printed in that case. -- Nikos Mavroyanopoulos From wk at gnupg.org Thu May 13 09:36:26 2004 From: wk at gnupg.org (Werner Koch) Date: Thu May 13 09:37:17 2004 Subject: concerning libgpg-error In-Reply-To: <200405121211.44973.nmav@gnutls.org> (Nikos Mavroyanopoulos's message of "Wed, 12 May 2004 12:11:44 +0300") References: <200405121211.44973.nmav@gnutls.org> Message-ID: <87ekpobwxx.fsf@vigenere.g10code.de> On Wed, 12 May 2004 12:11:44 +0300, Nikos Mavroyanopoulos said: > I bring again the libgpg-error issue. Would it be possible to > add the required functions for libgcrypt (without gettext and the extra > stuff), in a single object which will be compiled if libgpg-error is not > found in the system[0]? This would make the library much easier to This is a problem. Sooner or later another application will require libgpg-error and than we get into the problem of duplicate symbols or - if we take them out of the linker's scope - that other application won't be able to display proper i18n'd messages or you will see a translation or no translation depending on where the error gets printed. Adding libgpg-error as an independent part to libgcrypt would be possibe but be a headache for maintenance. Salam-Shalom, Werner From nmav at gnutls.org Thu May 13 10:33:11 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Thu May 13 10:27:55 2004 Subject: concerning libgpg-error In-Reply-To: <87ekpobwxx.fsf@vigenere.g10code.de> References: <200405121211.44973.nmav@gnutls.org> <87ekpobwxx.fsf@vigenere.g10code.de> Message-ID: <200405131133.12019.nmav@gnutls.org> On Thursday 13 May 2004 10:36, Werner Koch wrote: > > I bring again the libgpg-error issue. Would it be possible to > > add the required functions for libgcrypt (without gettext and the extra > > stuff), in a single object which will be compiled if libgpg-error is not > > found in the system[0]? This would make the library much easier to > > This is a problem. Sooner or later another application will require > libgpg-error and than we get into the problem of duplicate symbols or > - if we take them out of the linker's scope - that other application > won't be able to display proper i18n'd messages or you will see a > translation or no translation depending on where the error gets > printed. That's why a warning should be issued. This is due to an administrative decision so such behaviour is acceptable (they should install libgpg-error to avoid that). In any case my proposal was for systems that do not need internationalization such as constrained systems etc. Also porting is much more work with interlibrary dependencies and this change would help a lot. > Adding libgpg-error as an independent part to libgcrypt would be > possibe but be a headache for maintenance. Not a fully working gpg-error is expected to be included. Just the minimum part of it that is required for it to work. Only the .h file should be updated if new error values are used in libgcrypt. If this is not possible a disable option to disable completely error printing (and thus the dependency to libgpg-error) would also help. > Salam-Shalom, > Werner -- Nikos Mavroyanopoulos From wk at gnupg.org Thu May 13 12:12:47 2004 From: wk at gnupg.org (Werner Koch) Date: Thu May 13 12:12:15 2004 Subject: concerning libgpg-error In-Reply-To: <200405131133.12019.nmav@gnutls.org> (Nikos Mavroyanopoulos's message of "Thu, 13 May 2004 11:33:11 +0300") References: <200405121211.44973.nmav@gnutls.org> <87ekpobwxx.fsf@vigenere.g10code.de> <200405131133.12019.nmav@gnutls.org> Message-ID: <87n04cab4w.fsf@vigenere.g10code.de> On Thu, 13 May 2004 11:33:11 +0300, Nikos Mavroyanopoulos said: > minimum part of it that is required for it to work. Only the .h file should > be updated if new error values are used in libgcrypt. If this is not possible and that is excaly what makes maintenance hard. > a disable option to disable completely error printing (and thus the > dependency to libgpg-error) would also help. Disabling error printing is a Bad Thing. You will get weird bug reports taking a long time to duplcate them and finally it is a simple thing which could have been figured out by the error message directly. After all we went for this shared libary with markers for the subsystem to make bug tracking easier. By not having a central place to maintain this information (the shared library) this effort would be rendered mostly fruitless. What is the real problem you have with libgpg-error? Does it not build cleanly on all systems? I'd like to hear about such things ASAP. Shalom-Salam, Werner From nmav at gnutls.org Thu May 13 13:13:39 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Thu May 13 13:07:33 2004 Subject: concerning libgpg-error In-Reply-To: <87n04cab4w.fsf@vigenere.g10code.de> References: <200405121211.44973.nmav@gnutls.org> <200405131133.12019.nmav@gnutls.org> <87n04cab4w.fsf@vigenere.g10code.de> Message-ID: <200405131413.39454.nmav@gnutls.org> On Thursday 13 May 2004 13:12, Werner Koch wrote: > > a disable option to disable completely error printing (and thus the > > dependency to libgpg-error) would also help. > Disabling error printing is a Bad Thing. You will get weird bug Well error printing the way libgpg-error does, is only usefull to applications such as gnupg. For gnutls which is a low level wrapper library over libgcrypt it is just unused code. > reports taking a long time to duplcate them and finally it is a simple > thing which could have been figured out by the error message directly. > What is the real problem you have with libgpg-error? Does it not > build cleanly on all systems? I'd like to hear about such things > ASAP. I don't have anything with libgpg-error. I just want an option to disable it if I don't need it at all since it makes it harder to compile libgcrypt and adds unused code. Your concerns when adding an option to disable it are for end user distributions which will of course include it, since they want error reporting. On the other hand embedded servers that only use gnutls over libgcrypt don't need it at all. > Shalom-Salam, > Werner -- Nikos Mavroyanopoulos From marcus.brinkmann at ruhr-uni-bochum.de Thu May 13 13:56:56 2004 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu May 13 14:00:47 2004 Subject: concerning libgpg-error In-Reply-To: <200405131133.12019.nmav@gnutls.org> References: <200405121211.44973.nmav@gnutls.org> <87ekpobwxx.fsf@vigenere.g10code.de> <200405131133.12019.nmav@gnutls.org> Message-ID: <873c6435h3.wl@ulysses.g10code.de> At Thu, 13 May 2004 11:33:11 +0300, Nikos Mavroyanopoulos wrote: > On Thursday 13 May 2004 10:36, Werner Koch wrote: > That's why a warning should be issued. This is due to an administrative > decision so such behaviour is acceptable (they should install libgpg-error > to avoid that). In any case my proposal was for systems that do not need > internationalization such as constrained systems etc. You can disable i18n when compiling libgpg-error (--disable-nls). > Also porting > is much more work with interlibrary dependencies and this change would > help a lot. That's hardly true. > > Adding libgpg-error as an independent part to libgcrypt would be > > possibe but be a headache for maintenance. > Not a fully working gpg-error is expected to be included. Just the > minimum part of it that is required for it to work. Only the .h file should > be updated if new error values are used in libgcrypt. If this is not possible > a disable option to disable completely error printing (and thus the > dependency to libgpg-error) would also help. We don't optimize the software for the rare cases. If you have a genuine need to keep things small, you can compile libgpg-error with disable-nls, and link statically to it. If you don't use gcry_strerror, it should not link in the error strings. Thanks, Marcus From wk at gnupg.org Thu May 13 14:38:41 2004 From: wk at gnupg.org (Werner Koch) Date: Thu May 13 14:37:17 2004 Subject: concerning libgpg-error In-Reply-To: <200405131413.39454.nmav@gnutls.org> (Nikos Mavroyanopoulos's message of "Thu, 13 May 2004 14:13:39 +0300") References: <200405121211.44973.nmav@gnutls.org> <200405131133.12019.nmav@gnutls.org> <87n04cab4w.fsf@vigenere.g10code.de> <200405131413.39454.nmav@gnutls.org> Message-ID: <871xloa4dq.fsf@vigenere.g10code.de> On Thu, 13 May 2004 14:13:39 +0300, Nikos Mavroyanopoulos said: > distributions which will of course include it, since they want error > reporting. On the other hand embedded servers that only use gnutls > over libgcrypt don't need it at all. Don't forget about applications using gnutls directly and indirectly as it is very common if one uses LDAP. Salam-Shalom, Werner From wk at gnupg.org Thu May 13 14:37:22 2004 From: wk at gnupg.org (Werner Koch) Date: Thu May 13 14:37:26 2004 Subject: concerning libgpg-error In-Reply-To: <873c6435h3.wl@ulysses.g10code.de> (Marcus Brinkmann's message of "Thu, 13 May 2004 13:56:56 +0200") References: <200405121211.44973.nmav@gnutls.org> <87ekpobwxx.fsf@vigenere.g10code.de> <200405131133.12019.nmav@gnutls.org> <873c6435h3.wl@ulysses.g10code.de> Message-ID: <8765b0a4fx.fsf@vigenere.g10code.de> On Thu, 13 May 2004 13:56:56 +0200, Marcus Brinkmann said: > disable-nls, and link statically to it. If you don't use > gcry_strerror, it should not link in the error strings. Furthermore, we could eventually work together on a common set of error codes and add the gnutls specific ones to libgpg-error. Obviously only for the next gnutls API as. gnutls is also a very basic library and having one set of error codes will make things for applications easier. Shalom-Salam, Werner From zozo at rubin.hu Mon May 24 16:14:47 2004 From: zozo at rubin.hu (Dede Zsolt) Date: Mon May 24 16:17:46 2004 Subject: Libgcrypt.dll Message-ID: <40B20357.3030509@rubin.hu> Hi I can't compile a libgcrypt.dll from a libgcrypt 1.2.0 sorce. Please help me, send this dll for me, if you have it. Thanls. Zsolt Dede