On Tue, Dec 10, 2013 at 11:15 AM, Werner Koch wk@gnupg.org wrote:
Well, I really want to think that it is also about collaboration.
Right, I thought about the same lines but back then Niels decided to compile his own library without the need to comply to the strict GNU rules. Thus he was able to use all kind of code while I was not. A decade or more ago I had to reject Brian Gladman's offer to use his code due simply due to the CA requirement. Latter then the GNU project seems to have concluded that CAs are not important anymore unless they are already in use. The effect was that GNUTLS silently started to use Nettle instead of helping to convince the GNU towers to drop the CA requirement for Libgcrypt.
I thought that this was done quite vocally :) There was quite a long discussion in this list about the issues I had back then, that if I remember well were (a) libgcrypt could not be used in setuid processes, and (b) that it was much slower -more than 2x- than openssl (and nettle). The conclusion of that discussion was that libgcrypt wouldn't change. I now understand that (b) was because you were strictly following the gnu rules, but that provided no comfort to me who was seeing gnutls being at the bottom of any benchmark. That's why I switched to nettle and as it is now we are more than 2x faster compared to openssl in public key operations.
While I understand that everyone has a different agenda on the things that need to be done, schedules etc., a compromise that will benefit everyone may be possible.
Well, you removed all support for Libgcrypt from GNUTLS. If you want to use it again, you only need to add that layer again.
I removed it because I changed the internal API and libgcrypt support would be incomplete (gcm was missing at the time). I don't think it is would be trivial to re-add, but it is not hard either. Nevertheless, even if such a switch would be possible today, it would solve nothing, as now we have some few parts that libgcrypt is better than nettle, and other parts which nettle is better than libgcrypt. My argumentation for the merging was with the intention to have the best implementations of each library merged.
regards, Nikos