grothoff at cs.purdue.edu
Wed May 5 23:10:09 CEST 2004
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
> >> > 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.
More information about the Gcrypt-devel