[Pkg-clamav-devel] remaining clamav bugs

[Scott Kitterman]

On Wednesday, July 09, 2014 22:28:37 Andreas Cadhalpun wrote:
> 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.

I spoke with laterra on IRC (he's a clamav developer at Cisco/Sourcefire) and 
he said he'd take a look at the patches in all four bugs this weekend.  Some 
of them may yet make 0.98.5 final.

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

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.  If we could find out what is matching it, then it'd be great to file a 
bug against lintian.

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

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.

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

I will do this, probably over the weekend.

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

Scott K