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
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
Well, I really want to think that it is also about collaboration.
On Tue, Dec 10, 2013 at 11:15 AM, Werner Koch wk@gnupg.org wrote:
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.
I'm sorry you feel like this. There are historic reasons (and the first release of Nettle happened more than a decade ago). The code started as the Pike cryptographic toolkit which I and Henrik Grubbström did in 1996 or so, we needed this to implement SSL for the Roxen webserver, which is written in Pike (Henrik first wrote some glue to use openssl, or "ssleay" as it was known back in the day, but we then decided to write our own SSL implementation).
This was GPLd, but neither Pike nor Roxen are GNU projects, copyright assignments were never considered. A few years later, 1998, I started on LSH, and reused the low-level C code. Half a year later, LSH was dubbed a GNU package, with no large changes to the way it was developed. No copyright assignment policy was imposed at that time (and since I wasn't the sole author, it wouldn't have been trivial).
Then Nettle was spun off from LSH in 2001. Time went by, and in 2009 it was dubbed a GNU package on its own, despite concerns about duplication with libgcrypt. Maybe I could have done some things differently back then, but I can't feel particularly guilty.
So what about today? Is FSF copyright assignment important to you, and lack of Nettle CA a main show stopper for using Nettle in any way? I'd like to know the obstacles, technical or other.
It would be possible, although some amount of boring work, to transfer most nettle copyrights to the FSF. I think I understand both the advantages and disadvantages which come with FSF copyright assignment.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se