Bugzilla Bug 245450

ClamAV-0.94.1 was released today, I think.

Reproducible: Always

Steps to Reproduce:

Created an attachment (id=170653) [details]
replaces clamav-0.94-buildfix.patch because of changes in configure.in

version 0.94.1 of clamAV changed the configure.in script enough to prevent the
previous patch from working.

Created an attachment (id=170655) [details]
fixes libtool issue, adds deps for FEATURES=test, adds ipv6 useflag

The new clamAV release includes some files from the newer version of libtool in
m4/. This ebuild deletes m4/{libtool,lt*}.m4 because stable Gentoo users will
come up with weird errors such as I described in
https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1251 .
Also this patch adds inheritance of the versionator eclass. This is used to
support renaming the ebuild to clamav-0.94.1_rc1.ebuild, which I did, because
clamav named the package clamav-0.94.1rc1.ebuild (they left out the
underscore).
This patch also adds the ipv6 useflag, since there is optional ipv6 support
{en/dis}able-able through the configure script.
And, this ebuild patch adds dependancies for the tools clamAV uses to test
itself for when FEATURES=test. However, I think clamAV-0.94.1 and
clamAV-0.94.1_rc1 will fail its valgrind tests unless if bug #245226 is fixed
or a patch is made to unit_tests/valgrind.supp to support running valgrind's
helgrind under libsandbox.so.

*** Bug 246176 has been marked as a duplicate of this bug. ***

(In reply to comment #1)
> Created an attachment (id=170653) [edit] [details]
> replaces clamav-0.94-buildfix.patch because of changes in configure.in
> 
> version 0.94.1 of clamAV changed the configure.in script enough to prevent the
> previous patch from working.
> 

Thanks for your ebuild Nathan, I'll take a look at it (and probably commit it)
later on this evening.

(In reply to comment #4)
> Thanks for your ebuild Nathan, I'll take a look at it (and probably commit it)
> later on this evening.
> 

I encounter failing DUMA tests - i'll need to take at look at it tomorrow.

(In reply to comment #5)
> 
> I encounter failing DUMA tests - i'll need to take at look at it tomorrow.
> 
Are you using amd64? If so, you may have experienced the same bug #243332 - the
stable duma always crashes for me, while the unstable one doesn't (though I'm
not extensively testing it)

(In reply to comment #4)

> 
> Thanks for your ebuild Nathan, I'll take a look at it (and probably commit it)
> later on this evening.
> 

You're welcome.

I'd just like to comment on the progress of bug #245226 which became a dup of
bug #235581. To compile and test ClamAV successfully with FEATURES="sandbox
test", the svn trunk version of sandbox is needed. From what I understand, for
the current version of sandbox (version 1.2*), the "sandbox" or "usersandbox"
and "test" FEATURES flags would be mutually exclusive for ClamAV. My ClamAV
ebuild installs fine with FEATURES="usersandbox sandbox -test" and
FEATURES="-sandbox -usersandbox test".

Valgrind's helgrind reports errors about sandbox-1.2* when make check runs a
ClamAV executable. This is because ClamAV is multithreaded and is rooted in bug
#235581.
However, ClamAV hasn't segfaulted on my machine because of the bad
sandbox-1.2*. This leaves, in my opinion, three options for supporting users
with FEATURES=test:
1. Warn the user to choose betewen FEATURES="sandbox usersandbox -test" and
FEATURES="test -sandbox -usersandbox"
2. Patch the ClamAV test suite to add the valgrind suppressions I listed in bug
#245226 if the user has sandbox-1.2* installed. This allows the testsuite to
actually test the ClamAV code, ignoring errors in the user's sandbox
installation (which is guaranteed to be wrong).
3. Change the  to require a version of sandbox that isn't yet in the Portage
tree, but only if the test useflag is enabled. My patch has a pair of lines
which would be changed to something like:
-       test? ( dev-libs/check )
+       test? ( dev-libs/check dev-util/duma dev-util/valgrind
>=sys-apps/sandbox-1.2.20 )
This would allow people to install the package with FEATURES="-test" and would
automatically work for FEATURES="test" when the next version of sandbox comes
out. 

I'm not sure which choice is best, but I'm guessing that you'll want a quick
fix because of the "buffer overflow vulnerability" in older ClamAVs. Maybe an
ewarn about building with FEATURES="test" would be enough.


Concerning dependencies in general: I think the conditional dependencies for
the "test"
useflag should be moved from COMMON_DEPEND into DEPEND. I'm pretty sure that no
code linked to dev-libs/check is installed. Running ldd on all the clamav
binaries showed no links to /usr/lib*/libcheck.so*. Thus, RDEPEND shouldn't
have the dependencies used for testing ClamAV in it.

(In reply to comment #6)
> > I encounter failing DUMA tests - i'll need to take at look at it tomorrow.
> > 
> Are you using amd64? If so, you may have experienced the same bug #243332 - the
> stable duma always crashes for me, while the unstable one doesn't (though I'm
> not extensively testing it)

hrm, yeah ... duma-2.5.13 works for me on amd64, adjusted the dep.

> Concerning dependencies in general: I think the conditional dependencies for
> the "test"
> useflag should be moved from COMMON_DEPEND into DEPEND. I'm pretty sure that no
> code linked to dev-libs/check is installed. Running ldd on all the clamav
> binaries showed no links to /usr/lib*/libcheck.so*. Thus, RDEPEND shouldn't
> have the dependencies used for testing ClamAV in it.

Also moved the test deps into COMMON_DEPEND.

So, 0.94.1 is inCVS. I had to drop the following keywords due to either
valgrind or duma not being keyworded (or both of them):

  KEYWORDS.dropped              1
   app-antivirus/clamav/clamav-0.94.1.ebuild: alpha hppa ia64 ppc64 sparc
x86-fbsd

Also we'd need duma-2.5.13 stable for the tests to pass (at least on amd64).
Plus tests won't pass when run with sandbox enabled (it's supposed to be fixed
in sandbox svn, which won't help us for now), so expect tests to pass with a)
>=duma-2.5.13 and b) FEATURES="-sandbox".

Okies, we had a quick vote on #gentoo-security, 3 out of 3 voted to restrict
tests for now. I committed that change and re-added the dropped keywords. There
we go :)

Arches, please test and mark stable:
  =app-antivirus/clamav-0.94.1

Target keywords: alpha amd64 hppa ia64 ppc ppc64 sparc x86

ppc64 stable

Stable for HPPA.

alpha/ia64/sparc/x86 stable

amd64 stable

ppc stable

(In reply to comment #9)
> Arches, please test and mark stable:
>   =app-antivirus/clamav-0.94.1
> 
> Target keywords: alpha amd64 hppa ia64 ppc ppc64 sparc x86
> 

app-antivirus/clamav-0.94.1 is stable for all of the above keywords. It seems
this bug is fixed.

re-open, the GLSA needs to be send out before this one can be closed.

GLSA 200812-21