[gnutls-dev] Re: living without global variables

[Werner Koch]

On 3 Jan 2006 01:32:40 +0000, Bryan Henderson said:

> Doesn't it?  gnutls' global init function does _something_ with
> Libgcrypt.  How is that different?

Gnutls handles the Libgcrypt initialization internally and thus
requires that the user of gnutls has knowledge about the internal use
of libgcrypt.  If you are using libgcrypt in a threading environment
the gnutls callers needs to make sure that Libgcrypt has been
initialized correctly - the last time I checked, gnutls does not know
the threading system in use and thus can't initialize Libgcrypt properly.

With an initialization function similar to the one of Libgcrypt it
would be possible to hide the use of Libgcrypt.

We do not create thread specific versions of Libgcrypt because this
would require all libs using Libgcrypt to also come in different
flavors (plain, pthread, pth) - not very efficient.  For certain OSes
we might be able to do some trickery in detecting and initializing the
threading lib in use but this is not portable.

> Assuming you have to have global variables, of course.

The major reason for global state is the entropy pool.  Collecting
entropy is a time consuming task and we can't do it for each new
session.  Another one is libgcrypt's "secure" memory allocation
functions - obviously this can't be done on a per session base or
delegated to a daemon.  With encrypted swap you won't need it, but
this OS feature is not yet in widespread use.

Thus this is all a matter of telling libgcrypt to use the correct
threading system.

Unloading Libgcrypt is not possible unless all users agree on shutting
down all threads (but one) using Libgcrypt, restoring all hooks and
releasing all secure memory.  Libgcrypt can't detect such a condition
and this is the reason we don't provide a deinit function.

For a plugin system one could use wrapper functions to provide a
managed interface to libgcrypt.  The problem is that you need to do
this for most libraries which are subject to "unloading" and change
all those libraries to use these wrapper functions.  Writing a plugin
system in a portable way is not easy.  Frankly, I see no way to create
in-process plugins without restricting the APIs a plugin may use.
Creating plugins as separate processes is far easier, more secure and
really portable.


Shalom-Salam,

   Werner