Gratuitous gcry_fast_random_poll

[Christian Grothoff]

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