[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: openssl vs. libgcrypt
From: |
Werner Koch |
Subject: |
Re: openssl vs. libgcrypt |
Date: |
Wed, 13 Dec 2006 17:27:05 +0100 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) |
On Tue, 12 Dec 2006 20:11, address@hidden said:
> A generous volunteer (Logan Gabriel, cc'd) has been discussing offering
> a long-time project of his for system integrity checking to GNU.
[ I have always thought that AIDE is the GNU project for it. It was one
of the first projects using libgcrypt. ]
> One of the things the project needs is ssl-ish computations,
> such as provided by libgcrypt and openssl.
You mean it needs TLS/SSL or crypto basics? For TLS GNUTLS is the
library of choice.
> My immediate question is, is there some known/recommended set of
> configure options for switching between these libraries?
I don't know. There is a compatibility layer in GNTLS for OpenSSL but
it is very limited. I don't know of other projects which allow to
switch the crypto backend.
> wget currently has these:
Ah well, there is one.
> Perhaps these options could be extended. If (say) --with-ssl=libgcrypt
> is given, it would look for that library, using the libssl-prefix to
> do so, if specified. Similar if given --with-ssl=libopenssl.
If it is not about TLS, the naming is wrong. A
--with-cryptolib=crypt|openssl|gcrypt|tomcrypt|beecrypt
looks better. However libcrypt (by Peter Gutmann) is GPLed and will
leed to problems for LGPLed libraries.
> I gather the libgcrypt and openssl api's are not the same. Logan was
> going to implement a compatibility layer for the functionality he
> needs. Anyone have knowledge of previous work in this area?
No. The OpenSSL API is not easy to understand and use; I wonder why
it would make sense to support it at all. The other libs have more
starightforward APIs.
> Finally, there is the painful licensing problem. About all I can think
> of is to use the same special exception that is included with wget.
OpenSSL is a major problem. We have the problem all over our systems:
App -> libfoo -> libldap -> libopenssl
Thus in the end all applications need to come with the OpenSSL
exception. It is even worse because sometimes you see dependecies
like:
App -> libfoo -> libldap -> libopenssl
+-----> libgnutls -> libgcrypt
+-----> libopensc -> libpcsclite
+------> libopenssl
libcurl is also an example of a commonly used lib which in turn uses
OpenSSL. I think it is better to put some effort into replacing
OpenSSL by LGPLed code than to work on compatibility layers. These
license incompatibilities drive me crazy.
Salam-Shalom,
Werner