[Pkg-clamav-devel] remaining clamav bugs

[Andreas Cadhalpun]

Hi,

On 09.07.2014 22:43, Scott Kitterman wrote:
> On Wednesday, July 09, 2014 22:28:37 Andreas Cadhalpun wrote:
>> On 07.07.2014 06:43, Scott Kitterman wrote:
>>> On a related note, any ideas what we need to do to get away from:
>>>
>>> libclamav6 binary: embedded-library usr/lib/libclamav.so.6.1.23: zlib
>>>
>>> As far as I can tell, we're using the upstream zlib, so it's a matter of
>>> dynamically linking it, right?
>>
>> I'm not sure what you mean here. As I understand it, this lintian error
>> is a false-positive, which is why it's overridden.
>>
>> Indeed, libclamav6 is already dynamically linked to zlib:
>> $ ldd /usr/lib/libclamav.so.6.1.23 | grep libz
>> 	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fce7c434000)
>>
>> Lintian uses a perl regex [1] to detect zlib:
>> (?m)(?<!4 )(?:in|de)flate (?:\d[ \w.\-]{1,20}[\w.\-])
>>
>> I'm not sure what string in libclamav this matches, but comparing this
>> with the strings lintian matches for other libraries, it seems quite
>> generic. Looking at the affected packages [2], it seems this tag is
>> always overridden, so maybe a bug report against lintian should be
>> opened about this.
>
> It's always overridden because it's on the FTP master autoreject list if not
> overridden.  You either override it or your package doesn't get in the
> archive.

So that's the reason...

> If we could find out what is matching it, then it'd be great to file a
> bug against lintian.

The matched string is:
$ strings /usr/lib/libclamav.so.6.1.23 | grep -P '(?m)(?<!4 
)(?:in|de)flate (?:\d[ \w.\-]{1,20}[\w.\-])'
  inflate 1.2.3 Copyright 1995-2005 Mark Adler

This is actually what lintian wants to detect.
It's defined in libclamav/inflate64.c, which is a modified version of 
zlib's inflate.c, defining inflate64* functions, that are not available 
in zlib.

I don't think lintian can detect that, so we probably should just add a 
comment to the lintian override, explaining the situation.

>>> Agreed.  I don't mind doing it the next time clamav has to hit new anyway.
>>
>> As there is no SO bump now, it's unlikely clamav will need to go through
>> NEW soon. I think we shouldn't wait indefinitely for that.
>
> The backlog in New is very long right now and we've got 0.98.5 coming up, so
> I'd rather not do it now.

I'm aware of the large backlog in NEW. :(
But maybe we can do the split in time for jessie.

Best regards,
Andreas