[Help-gnutls] Re: gnutls multi-threaded

[Simon Josefsson]

Daniel Stenberg <address@hidden> 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