Daniel Stenberg <daniel_at_haxx.se> writes:

> Reading another thread in the gnutls list, it came to my attention that using
> GnuTLS in a multi-threaded environment requires some locking functions to be
> set for the underlying crypto lib (libgcrypt).

Hi! Yes, this is sadly the situation right now. I don't particularly
fancy libgcrypt's design choice when it comes to threading. That has
been one of the reasons to work on modularizing the crypto stuff in
GnuTLS. Alas, I haven't had time to finish it yet. The goal is to be
able to replace libgcrypt with something else, and also include a
minimalistic and portable crypto library (e.g., Nettle). Then GnuTLS
will be able to build as a standalone package, which is better for
testing.

I have started on a backend agnostic crypto API, called "Generic
Crypto", it is in gnutls/crypto/ right now. This is (or will be) used
by GnuTLS, Shishi, GNU SASL, and possible other projects, and support
libgcrypt and Nettle as crypto-backends. It does hashing, randomness,
and symmetric ciphers now. Adding multiple-precision computations,
public-key operations, s-exp and possibly more is an area which could
use some help. Any comments on the interfaces are appreciated.

> Is there a descriptive web page anywhere that explains this that I can point
> libcurl users to?

Eric Leblond answered this, I think.

> Many libcurl users run multi-threaded programs and this is
> bound to hit the fan as soon as people start trying the GnuTLS-version of
> libcurl more.

Right.

> I'm considering providing this locking/mutex ability in an API to libcurl, so
> that libcurl-using apps can be agnostic to which secure layer libcurl has been
> built to use. But I don't know yet if that is feasable.
>
> Is there a good reason why GnuTLS doesn't export such methods by itself? I
> mean, isn't it rather ugly to force lib-users to have to assume that GnuTLS
> uses libgcrypt?
>
> Or have I misunderstood things?

No, and I agree with you, it is not elegant now. One problem with
adding these methods is that it suggest to people that they should
always use them, and that it is a good thing to use them, which I
think sends the wrong signals. But as you say, it may be even more
inelegant to force GnuTLS users to use libgcrypt directly. I think
these locking/mutex hooks should be added to the GnuTLS API. Patches
welcome..

Regards,
Simon
Received on 2005-04-13