libgcrypt 1.1.93 released

[Werner Koch]

On Tue, 9 Mar 2004 15:08:19 +0200, Nikos Mavroyanopoulos said:

> locking, unless explicitely requested. That is an application that
> uses pthread calls something like gcry_enable_pthread_locks() etc.
> Is this a viable solution? 

Because you need to propagate such a call up to the actual application
possible through many library layers.  OpenLAP is just one example and
I bet OpenLDAP is also used in other libraries without the users
realizing it.

> Since the only non-reentrant part is the random generator, an other 
> solution would be to add a thread safe random number generator api 

No it is not. There are several places like self tests, initialization
code and first of all module registration.

> Another solution would be for libgcrypt to fork a rng proccess,
> and communicate using IPC with it. This would be certainly thread
> safe (however this only works in systems with fork() available).

Then you would end up with several RNG processes because libgcrypt
won't be able to track whether one has already been
started. Anyway, the RNG is not the only place where we need at
locking and access to system functions.

  Werner