libgcrypt 1.1.93 released

[Marcus Brinkmann]

At Tue, 9 Mar 2004 15:08:19 +0200,
Nikos Mavroyanopoulos wrote:
> 
> On Tue, Mar 09, 2004 at 01:20:06PM +0100, Marcus Brinkmann wrote:
> 
> > We considered the situation, and the issue is fundamental.  There is
> > no solution we know of.
> > First, the automatic thread detection was a fancy idea, but it isn't
> > very portable and it is not very reliable either.  You could get the
> > linking wrong easily (esp with libtool) and had no way to know - there
> > was no error detection at all.
> Hello Marcus,
>  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? 

Not really.  There are two reasons, a technical one and a policy one.
The technical reason is that linking with pthreads usually has serious
side effects.  You can't just link an application that was compiled
without pthread with pthread and hope it will work (there have been
problems with that for example with apache and some plugins in the
past).  The reason is that pthread replaces library calls like
read/write (IIRC) and signal handling.  I don't have a complete
picture what it does exactly, but it's not as with any other library
which you just link to your program and nothing will happen.

The policy reason is that as a consequence, you have to export the
interface to the application if you use gcrypt in a library.  IE, a
library like gnutls would have to provide an interface for the
application to switch to the thread library it wants, and so on,
through all intermediate libraries.  We don't fancy such a solution
very much.  If we wanted it, there would be a good solution indeed:

"Don't link to any thread library, but provide a function to set
callbacks for locking and I/O operations."

This would be a clean solution, but the policy reason above makes it
inelegant.

> 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.

I don't know gcrypt internals to say if that is the only problematic
location in the code.  It very well might be (I assume you have
checked :), but there might be others in the future.  Plus, we also
have this issue in gpgme, which is I/O intensive and calls
sub-processes, and we would like a common solution if possible (for
maintenance reason).  But all of that would not be convincing if the
solution you propose wouldn't have the exact problem as I wrote above,
namely that you'd then have to pass on the interface in every
intermediate library to the application level.
 
> 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).

Mmh, it's an interesting idea.  However, it appears to me that any
such solution would end up to be specifically tailored around one
particular issue (random pool in gcrypt here).  It's much more
preferable (for obvious reasons) to have a common solution.

All in all, good suggestions.  Keep it going!  In particular, don't be
shy to tell me if you think my above counter-arguments are not sound
or incomplete.  We are very much open for a discussion of this.  We
only believe to have thought it all through, we have not proven it :)

Thanks,
Marcus