[Pkg-clamav-devel] remaining clamav bugs

Wed Jul 9 20:28:37 UTC 2014

Hi,

On 07.07.2014 06:43, Scott Kitterman wrote:
> On Thursday, June 26, 2014 22:13:25 Sebastian Andrzej Siewior wrote:
>> On 2014-06-25 01:54:06 [+0200], Andreas Cadhalpun wrote:
>>> I have been going over the remaining clamav bugs and closed those, which I
>>> found invalid.
>>>
>>> As I understand it, the situation for the remaining bugs is:
>>>
>>> Forwarded bugs:
>>>   * #636881: waiting for upstream inclusion
>>
>> yes
>
> I pinged upstream in the bug.
>
>>>   * #690788: waiting for upstream reply
>>>   * #690789: waiting for upstream reply
>>
>> Those two look similar as both are about web downloads. I asked upstream
>> to make them public. I have no idea what upstream did here but I guess
>> nothing. The easiest way to close/fix both is probably to use libcurl
>> for the download. I just browsed freshclam/manager.c which seems to do
>> the work here and it looks like they implemented everything (includung
>> proxy support) more or less from scratch.
>
> I filed those, so I have access.  If you want me to, tell me what address to
> add.  There is, I understand, a substantial freshclam change coming soon, so
> we should just wait on these to see what they are already doing.

Thanks to Sebastian, these two are now publicly available.
As they are not urgent, I think it's best to wait what upstream does 
with freshclam and ping them again, if these don't get fixed in the process.

>>>   * #740059: waiting for upstream inclusion
>
> Same with this.  I did also ping upstream in the bug.

It seems upstream is not opposed to include both patches (for #636881 
and #740059), but it's not clear when that will happen.
Until then, we could apply the patches in Debian, to see if they have 
any unintended side-effects.

>>>      None of the forwarded bugs are publicly accessible.
>>>      So has there been progress on any of them?
>>>      Maybe we should create an account for the pkg-clamav-devel list and
>>>      add it to the CC list of all these bugs.
>>
>> But then you still can't login and comment unless we share a common
>> login. I just asked upstream to make it public.
>
> In the meantime, if there are any of these you can't access, I can give you
> access since I filed them/have access.
>
>>>   * #295547: TODO: update patch -> ping upstream
>>
>> Yes, we could do that. In case nothing happens we could close this since
>> the reported said he does no loger care.
>
> Since this is really an upstream issue and there's no Debian user that cares,
> I think we should just close it.

Alright, it's probably not worth the trouble, as other programs might 
rely on the exit codes as they are now. So I'll close it as wontfix.

>>> Outstanding bugs:
>>>   * #636877: blocked by 636881
>>
>> So the best case scenario is once we get 636881 fixed, we can think how
>> we get that files removed on update :)
>
> Let's evaluate the best way after 636881 is fixed.  I usually use TCP sockets
> myself and avoid these kinds of issues.
>
>>>   * #675558: TODO: Can clamav be made to use the system libmspack?
>>
>> oh yes. This looks like fun. I think yes it should work. The purpose /
>> required functionality is the same.
>
> Upstream seemed very open to changes like this.
>
> 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.

>>>   * #393258: Should we split clamdscan from the clamd package and make
>>>
>>>              clamdscan only recommend clamd?
>>
>> It makes sense for the scenario mentioned.
>
> 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.

>>>   * #530520
>>
>> The mail mentioned in bug report is probably
>> http://archives.neohapsis.com/archives/postfix/2008-08/0797.html
>> It looks 100% harmless. The fix would be either for postfix not to open
>> a connection before we have the hostname (which makes me wonder why do
>> we need to resolve the hostname at all). The simpler way would be to drop
>> the message about host unknown.
>> We could add a reference to this email explaining the situation, drop
>> the check (or the resolve of the hostname in case it does not matter)
>> and see how upstream reacts.
>
> The reporter is still active in Debian and still uses postfix/clamav, so it
> might not hurt to ping him and see if this still happens.
>>
>> , #529986: What do you think about these?
>> Sounds usefull however I am not sure how many people care about his. The
>> popcon stats is quite low.
>
> I'd mark this wontfix.  It has marginal positive utility at best and makes mail
> delivery less reliable in general (I generally oppose black holing email).
> SMTP time reject is the best way to deal with it and with a milter you can do
> it effectively with postfix.

OK Scott, so could you take care of (ping/close) these two bugs?

>>>   * #234926: Wait for reply. Without that, close the bug.
>>
>> He does not care about his anymore, the initial usecase is no longer
>> valid.
>> It would be nice to have the same timestamp but it adds actually no
>> value. If we pull-in libcurl then we get mostlikely the correct
>> timestamp for the complete cvd file downloads. And the problem remains
>> probably for the case where the cvd file is an incremental update.
>> I would say we close this sice Marc no longer cares and the added value
>> has no meaning to anyone.
>
> I agree.  Close it.

So I'm closing it now.

> Thanks a lot.  You are both doing great work.  Keep it up.

:)

Best regards,
Andreas

1: 
http://sources.debian.net/src/lintian/2.5.24/data/binaries/embedded-libs?hl=104#104
2: http://lintian.debian.org/tags/embedded-library.html