[Pkg-clamav-devel] remaining clamav bugs

[Scott Kitterman]

On Thursday, June 26, 2014 22:13:25 Sebastian Andrzej Siewior wrote:
> On 2014-06-25 01:54:06 [+0200], Andreas Cadhalpun wrote:
> > Hi,
> 
> Hi,
> 
> > 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.

> >  * #740059: waiting for upstream inclusion

Same with this.  I did also ping upstream in the bug.

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

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

> >  * #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.

> >  * #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.

> >  * #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.

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

Scott K