Please test :)

David Shaw dshaw at JABBERWOCKY.COM
Tue Aug 25 21:03:55 CEST 2009


On Aug 25, 2009, at 8:45 AM, Werner Koch wrote:

> On Mon, 24 Aug 2009 03:46, dshaw at jabberwocky.com said:
>
>> which is what is linked with the keyserver helpers.  My notes say we
>> split libcompat and libutil in 2006 for licensing reasons, as the
>> keyserver helpers might be linked with OpenSSL, which is not GPL
>
> Right, I forgot about this.
>
>> Now, it would be possible to move the tilde expanding code to
>> libcompat (or even just implement things slightly differently), but I
>
> Yeah we should do that:  Add the exception to gnupg14/util/fileutil.c
> and make sure that it does not need other stuff from util/ .

Alas, it does.  It pulls in the memory allocation code (xmalloc and  
friends).  We could fairly easily make a ~ expander that doesn't use  
the other code though.  It's a shame we can't just use wordexp().

> Actually, I forgot about this problem while porting the keyserver code
> to GnuPG-2, or assumed that OpenSSL is not used.  Those who distribute
> GnuPG-2, need to take care of the license, meaning to use gnutls,  
> yaSSL
> or another GPL compatible SSL library.  In particular gnutls is a good
> choice because gnutls uses libgcrypt which is a requirement for GnupG
> anyway.

I worry this might be a excessive burden in some places.  It basically  
means that if a distribution builds Curl with OpenSSL, that  
distribution must build GnuPG without Curl.  Since Curl defaults to  
building with OpenSSL, and GnuPG-2 defaults to building with Curl,  
that requires the distribution builder to know about this potential  
license conflict and override the defaults somewhere in the GnuPG-2- 
 >Curl->OpenSSL chain.

I don't know how many distros fall into this category (I do know that  
Fedora is okay here), but any distro that follows the defaults will.

David




More information about the Gnupg-devel mailing list