[gnutls-dev] Re: living without global variables

[Simon Josefsson]

Werner Koch <wk at gnupg.org> writes:

> On Wed, 28 Dec 2005 10:13:52 +0100, Simon Josefsson said:
>
>> When we have a replacement for libgcrypt, we can reconsider this
>> issue, and then I think it would even be possible to get a thread safe
>> gnutls_global_init() -- the only remaining problem then would be the
>
> Indeed, Libgcrypt requires a call to an init fucntion and has for
> various reasons no deinit function.  This is due to the fact that
> Libgcrypt deliberately keeps global state (modules, random pool,
> self-tests, hooks, threading model).
>
> We discussed these issues for a long time and the only way to make
> Libgcrypt thread safe is by delegating the initialization to the
> actual application - only the application knows what threading model
> it is going to use.  Thus we use a macro to initialize the threading
> and then to lock things down the road.  The proper way for other
> libraries to use libgcrypt is by wrapping this init function and to
> allow the caller to actually initialize Libgcrypt (hidden in a
> wrapper function).

The distinction between a library and an application is rather blurry
nowadays.

I'm not convinced it scale to force applications to initialize all
libraries -- i.e., to force OpenOffice to initialize libgcrypt because
OpenOffice may use some component that eventually may dlopen some
library that may use gnutls that may use libgcrypt.

I'd rather have libraries initialize the libraries they use
internally, to make things modular.

> Unfortunately gnutls does not do this.

Improvements to the situation is welcome... I'm not sure it is
possible to solve Brian's problem without changing libgcrypt though.

> Bryan's session group function could be used to mitigate this
> problem as well.  However, this does not solve the problem of
> "unloading" libgcrypt.  In fact Libgcrypt should never be unloaded
> but kept in memory for the lifetime of the process.  Libgcrypt's
> init code silently ignores re-initialization and bails out only if
> the threading model is going to be changed.  There are plans to get
> rid of the global state but this would involve migrating some of the
> code out to a daemon.

I suppose the RNG stuff is the most problematic one.  For the
gnulib-crypto stuff, we will have to solve that aspect too, and there
may be some ideas there that could be re-used.

LSH's approach to this issue is interesting.  LSH require a disk file
with a RNG seed.  I assume that, after reading it, it is confounded
with some information that separate it from other processes that may
access the same RNG seed file.  This approach help on embedded
platforms where the entropy you can gather is scarce.  Then you could
generate a strong random seed when you burn the flashram.

/Simon