libgcrypt 1.1.93 released

[Marcus Brinkmann]

At Sun, 7 Mar 2004 20:17:19 +0200,
Nikos Mavroyanopoulos wrote:
> 
> On Sat, Mar 06, 2004 at 08:25:29PM +0100, Werner Koch wrote:
> 
> > Hi!
> > we just released libgcrypt 1.1.93; available at the usual places.
> 
> Hello Werner,
> I've noticed from the changelog that:
>  * The automatic thread library detection has finally been removed.
>    From now on, only linking explicitely to libgcrypt, libgcrypt-pth
>    or libgcrypt-pthread is supported.
> 
> Doesn't this break libraries like gnutls? There is no way for
> gnutls to know a priori which libraries an application would
> use. Should the applications that use gnutls deal with libgcrypt
> linking directly? Is there any easy way to do the linking with
> the proper library, using m4 macro or something?

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.

Well, the current situation is at least portable.  Plus, you can see
which thread library is supported (and thus its support is active) by
looking at the libraries you link with.  That's a small plus.

The problem of mis-linking is unfortunately still very real, and seems
not fixable.  You can link against libgcrypt and libgcrypt-pth and get
no error, not even a warning.  If anybody knows a solution to this,
we'd very much like to know about it.  Even a GNU-specific solution
would be welcome (and given the plethora of options in the GNU world,
there might be one).  At least you can easily find out that's the case
by looking at the library dependencies with ldd.

Now, for gnutls.  The fact that gcrypt is not thread-safe, and that
you need gcrypt-pthread (or gcrypt-pth) means that you have to make a
hard choice when developing your application or library that uses
libgcrypt.  Mind you, you had to do the same choice before, however,
before the choice didn't seem to involve gcrypt (in fact it did,
because it affected the linking order, but it was subtle and easy to
get wrong).

This means that if gnutls needs to be thread safe (and in that case
its maintainers have made the decision and gone a long way to ensure
that the gnutls interface and implementation is thread safe), then it
should link against the appropriate thread-safe version of gcrypt.
Yes, this might mean to have to provide gnutls, gnutls-pth and
gnutls-pthread.

There is an unfortunate side-effect. Mixing libraries will get things
very wrong.  If you mix a library that links against libgcrypt and a
library that uses libgcrypt-pth in your application, that's a bad
idea!  It might work, but it is officially unsupported (and I mean
it!).  It's similar to the problem of linking with mixed versions of
gcrypt, except that it is now in an orthogonal problem space (mixing
thread packages [incl no thread package at all]).  The chance someone
accidently linking against pthread and pth is pretty slim.  The chance
of someone linking against the non-threaded and a threaded version of
gcrypt is unfortunately very real.

Yes, this is not good.  In particular, as it is likely that
applications like KDE suck in gcrypt in the dozens via dependencies
like ldap.

Well, here is a bright side: If we (that means you ;) find a way to
make it work, transparently, and without ill side effects, then we can
revert back to the state of a single libgcrypt for all thread packages
on platforms where this is supported.  All three versions of the
library provide the same ABI and API.  So, with a few symlinks, you
can then unite them back.  However, until we have this, and I want to
stress that we have not made it easy fro ourselves on this issue, we
are stuck to expressing clearly the limitations that exist due to the
nature of how shared libraries work.

Somebody (maybe even we) might monitor how gcrypt is used in
applications and _libraries_ (that's the difficult case), and contact
problematic users.  The monitoring part can be automated with a
script.

Thanks,
Marcus