libgcrypt's global variable issues - statically linking it in application or not?

[Paul Wouters]

Hi,

There is a serious (long lived) bug in libgcrypt that can cause any
program to fail when two clients within the same program (eg plugins)
are trying to use libgcrypt.

This is because it uses global variables that the two clients both need to
use in the same address space in (potentially) different ways. Gaim-otr is
suffering from this, because it uses libgcrypt. If another module in gaim
uses libgcrypt, for example when LDAP is enabled and a TLS connection
is initiated through another plugin, or when using another encryption
plugin within gaim that uses libgcrypt directly, or indirectly via another
package or plugin using gnutls which uses libgcrypt, this bug pops up.

For various discussions of this bug, see:
http://lists.gnupg.org/pipermail/gcrypt-devel/2006-January/000889.html
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg304755.html

Having said this, I do not think Fedora's ldap packages depend on
libgcrypt, so enabling any kind of DNS functionality through ldap, as the
original Debian bug experiences, should not cause any problems on Fedora
(AFAIK!). I also see no gaim plugin packages in core or extras apart
from gaim-otr that uses libgcrypt, so from a practical point of view,
we have no issues *yet*. I personally have never been bitten by this
bug in all my years of using gaim-otr on Fedora.

The real question is, what should be done? A staticly linked libgcrypt
protecting those users who install non-fedora packaged software that might
trigger this bug, or postpone this issue until we actually see the libgcrypt
problem in fedora packaged software (while hoping the libgcrypt people fix
their global variable usage before we're bitten)?

If it was decided to statically link libgcrypt into gaim-otr, I would want
to use a Requires: that only points to the latest version of libgcrypt,
so that a rebuild of gaim-otr is forced when a new version of libgcrypt
is packaged.

I would like to hear what others are thinking about this issue.

Paul