libgcrypt 1.1.93 released

[Brieuc Jeunhomme]

>  Why no have a libgcrypt linked with both pthread and pth, but do no
> locking, unless explicitely requested. That is an application that
> uses pthread calls something like gcry_enable_pthread_locks() etc.
> Is this a viable solution? 

It may be better to have a gcry_set_locking_function(), because some
multithreaded applications do not use pthread nor pth. For instance,
about a problem I have with gnutls, I had to develop a clone() based
hack. libgcrypt shouldn't have to bother with the specific threading
implemention the application uses, should 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 
> (ie return handle of a pool), so the only one bothered with
> locking is the application.

Why not simply read "/dev/urandom" on OSes where it is available?

-- 
BBP