libgcrypt 1.1.93 released
wk at gnupg.org
Tue Mar 9 20:58:09 CET 2004
On Tue, 9 Mar 2004 19:23:12 +0200, Nikos Mavroyanopoulos said:
> 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
No. You can make this sure but 2 libraries higher this might not be
true anymore. And there is also the issue of applications like
interpreters, loading modules at will.
> So that would be one proccess per application. That's quite fair.
One process per thread.
> The current approach (1.1.93) makes all of the multithreaded applications
> using gnutls crash, that's why i'm most concerned about this.
A more severe problem is that applications may link to multiple
versions of Libgcrypt (or gnutls) and thus yield unexpected behaviour.
> 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.
But resulting in hard to track bugs. Hmmm, we might add the
old way as a fourth variant of libgcrypt (--thread=auto)
> Nikos Mavroyanopoulos
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
More information about the Gcrypt-devel