LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle)

[Werner Koch]

On Mon, 21 Feb 2011 15:03, nmav at gnutls.org said:

>  I know... My main issues with libgcrypt are that I
> got the impression that it is intended to be used
> as a back-end of gnupg and other uses are not
> considered or are considered as side-effects...

That is definitely wrong.  If that would be the case we would not have
gone into the trouble of maintaining a general purpose library.

> My main issues were:
> * performance... gcrypt is very slow in the software
> implementation of AES and SHA-1, comparing to

Depends on your hardware.  See my recent announcement.  In fact we did
some work on CFB and CBC performace to help GnuPG and gnutls more than 2
years ago.  SHA-2 performance was recently also improved.

Tuning of Libgcrypt is not not very complicated but it takes quite some
time.  Thus if I have to do it, I need to have a real use case.

> other libraries and nettle... Moreover it uses its

Please recall that Libgcrypt is a core GNU project and requires CAs.
Thus it is not possible to use some of the better tuned implementations.
Many years ago I discussed this with Brian Gladman: Although he then
allows to use his code under the GPL, we was not able to sign a
disclaimer of CA.  Thus we have to do this work ourself.

> own gmp that prevents from including all optimizations
> added to the original gmp library.

Let's not repeat this over and over again.  In short: At the time the
Libgcrypt code was written, tehre was no GMP development at all.  Later
GMP change the entire configuration system; which made it hard to re-use
the asm code.

> * mandates how the library is going to be used by
> using setuid etc... Why shouldn't a setuid application

Libgcrypt is about security and thus it uses secure defaults.  The
application is abale to chnage tehse defaults.

> perform TLS? Indeed there are risks but it should be
> the application developer to decide, not us.

I disagree.  Look at all the failures we have seen over last 20 years
with crypto code; most of them are due to "let the application developer
make sure it is used properly".  Libgcrypt tries to minimize the risks.

> * lack of low level functions to perform RSA/DSA/ECC.

Please explain.

> * gpg-error... adds a library dependence for something
> that is really simple and could be part of libgcrypt
> anyway. For non-gnupg applications there is nothing
> to be gained by this shared library.

Error management is not simple.  In fact, gnutls should have adopted
gpg-error as well.  For example, gpg-error allows to figure out the
subsystem which generated the error.  This is often very useful.  It is
very easy to use and does not require many code changes as other error
management systems do (look at GTK+).

> Especially performance is a big issue in gnutls, since e.g. in
> mod_gnutls we can have a server performing crypto with nettle
> in 50% load, while with libgcrypt the server is on it's capacity
> at 100% load. Those issues are better in libnettle. However

How do you measure load?  Why don't we discuss these things to find a
solution?


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.