libgcrypt 1.1.93 released

[Nikos Mavroyanopoulos]

On Tue, Mar 09, 2004 at 03:15:21PM +0100, Werner Koch wrote:

> > 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.
Those are unimportant enough to deserve such fuss. Initialization code,
and module registration happen only once and at the beginning of the
process so one shouldn't worry about reentrancy. As far as I remember
the self tests, also doesn't matter if they are protected by locks, since
in the worst case, they would be called more than once. In any case the 
tests could be moved to the initialization phase if anyone is concerned
about these.

> > 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. 
So that would be one proccess per application. That's quite fair.
You couldn't have a process per system, since then you'd have to deal
with security as well.

The current approach (1.1.93) makes all of the multithreaded applications 
using gnutls crash, that's why i'm most concerned about this.
The worst thing, is that I cannot do anything about it. Even if gnutls
used /dev/(u,a)random or other rngs, it would still fail, since libgcrypt
uses the internal rng in several places. I believe that the previous
behaviour should be kept (since it works), unless a better one is found.

>   Werner

-- 
Nikos Mavroyanopoulos