[Pkg-clamav-devel] clamav 0.98.3 released

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Sat May 10 10:23:30 UTC 2014


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 now 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?

>> 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).

Best regards,
Andreas


1: https://lists.debian.org/debian-devel/2014/01/msg00205.html



More information about the Pkg-clamav-devel mailing list