Daniel Stenberg <[EMAIL PROTECTED]> 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 _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
