[Pkg-clamav-devel] clamav 0.98.3 released

Scott Kitterman debian at kitterman.com
Sat May 10 15:57:39 UTC 2014


On May 10, 2014 6:23:30 AM EDT, Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:
>Hi,
>
>On 10.05.2014 09:16, Sebastian Andrzej Siewior wrote:
>> On Fri, May 09, 2014 at 08:13:27PM -0400, Scott Kitterman wrote:
>>>> GnuTLS has a compatibility layer for OpenSSL [1]. Using this, it
>might
>>>> be possible to simply switch the headers.
>>>> (We might get problems though: "Error handling is not thread
>safe.")
>>>
>>> Since clamav is only using openssl functions internally, packages
>that use libclamav
>>> don't need the openssl exception.  What they have is adequate for
>being in Debian.
>>> If they miss the exception in files where it should be, we should
>file bugs upstream.
>>> Given what is in the README, their intent is clear.
>>
>> Okay. So it is not a show stopper, good. I am only concerned because
>a) the
>> other deps on libclamav link against openssl and the crypto functions
>are
>> exported by libclamav.
>
>I'm a bit puzzled why it should be enough, if only clamav and not also 
>it's reverse-dependencies have an OpenSSL exception.
>
>In a recent thread on debian-devel [1] I found:
>"[...] that this [linking with OpenSSL] induces a problem (for
>Debian) for all GPL-without-OpenSSL-exception programs linked against
>libcups2. As far as I understand our current stance on that problem,
>GPL-licensed programs without an OpenSSL exception are absolutely
>forbidden to link with it, even indirectly."
>
>And therefore cups switched back from OpenSSL to GnuTLS.
>Am I missing something?

As I recall that discussion, cups was pretty directly exporting openssl functions in its own API. The clamav case is different because it's used internally only. 

You can't write a thin wrapper around a library and mask licensing issues, but equally, license issues don't inevitably propagate up the stack. 

I agree it's a tricky situation, but I think in this case it's fine. 

>>> I'd rather stick with what upstream is using and not switch to
>GNUtls.
>>
>> No problem. I got from Shawn:
>> |23:28 < lattera> bigeasy: mainly availability, openssl is
>everywhere, also has API functions for planned enhancements to
>freshclam
>> |23:29 < lattera> but, we've wrapped all the functions we currently
>use and the functions we plan to use later in libclamav/crypto.c, so if
>> |                 you wanna switch it out for another crypto lib, you
>just have to provide the same functions in your own crypto.c
>>
>> so it looks like he isn't against another library. Once we have the
>release
>> out I will try look at gnutls support and push it upstream.
>
>I fear we have to do that for this release, but, as said, I'm no expert
>
>in legal matters.
>
>About missing exceptions in many files, most of them have:
>#include <openssl/ssl.h>
>#include <openssl/err.h>
>#include "libclamav/crypto.h"
>
>From my point of view, it would have made more sense to put the OpenSSL
>
>includes in crypto.h, because one can't use it without also including 
>these OpenSSL headers, as some function parameters have types defined
>in 
>the OpenSSL headers.
>
>As it is, I'm not sure if these files need an OpenSSL exception.
>
>But there is also libclamav/conv.c, which has no OpenSSL exception, but
>has:
>#include <openssl/bio.h>
>#include <openssl/evp.h>
>
>This one definitely needs an OpenSSL exception (at least I think so).

Because the exception is included in the README, I think it's reasonable to believe they meant the exception to apply globally. On that basis, I would treat any missing declarations as bugs to be fixed, not licensing incompatibilities that make the result undistributable.

In my work as a Debian FTP Assistant I see far worse.

I believe what they did is alright, although not ideal. Fortunately, they are open to patches to integrate with GNUtls, so this can be a temporary concern. 

Scott K



More information about the Pkg-clamav-devel mailing list