Input for MOTU Meeting on Clamav

[Scott Kitterman]

On Thursday 26 April 2007 14:12, Scott Kitterman wrote:
> This agenda item should probably wait for a meeting that keescook can make
> it to (he's offline the rest of this week for travel).  I am unable to make
> today's meeting either.  Here is what I was thinking in case you go ahead
> and discuss it:
>
> Dapper and Edgy have clamav 0.8x.  Upstream has moved on to 0.9x and there
> are API changes that make a 0.9x backport outside the scope of what
> backport policy would permit.  OTOH, clamav is a security sensitive
> application and particularly for Dapper (because it's LTS) just leaving
> them stuck at 0.88 seems problematic.
>
> There is a new 0.88-4 package out from Debian for Sarge that we should
> probably look at for updating Dapper/Edgy, but in the end I think that the
> 0.88 series is not likely to be mainatinable for another 4 years.
>
> My suggestion is that we backport clamav 0.90.2 as a new backport package
> something like clamav-09 so that people who want to upgrade Dapper/Edgy can
> do so if they are willing to work through whatever breakage this causes
> elsewhere (I think clamav-daemon will work fine, but am not certain).
>
> I've built 0.90.2 on Edgy and Dapper.  Dapper took some minor dependency
> adjustment, but produced a functional package.  I'd be willing to put the
> initial backports packages on REVU, but am not qualified to keep them
> patched for new security issues.

I've continued looking into this and would like to discuss the following 
proposal for the next MOTU meeting (on Friday):

It looks to me like backporting clamav 0.90.x into Edgy/Dapper is far to 
risky.  The list of clamav rdepends is long and anything that depends on 
clamav (not necessesarily clamd) is definitely going to break.

My proposal is to do the following:

1.  Create a clamav-alt source package with all the binaries that would 
conflict with the existing clamav packages and provide all the clamav bits.  
This would be created in the current development branch and backported.  
Dependencies would be modified to make it reach as far back as a functional 
package could be created (for Dapper I could make a function 0.90.1 package - 
haven't tried 0.90.2 yet).

2.  Create a clamav testing team (I'll admin it) to test clamav-alt on the 
in-service releases.

3.  Create a wiki page to status the testing of the different clamav rdepends 
with clamav-alt so people know what they are going to break when they install 
it.

4.  Ref the wiki page in the clamav-alt package description so people have a 
good strong hint of what they are a getting into.

The alternative would be to actually maintain 0.88.2/4 and fix the open 
security issues in them.  I certainly don't have the expertise to do that and 
don't know of anyone else working in Universe who has the combination of 
expertise, time, and willingness.

I know backports aren't supposed to be for fixing stuff, but this seem to be 
the most executable path out of the current dilemma.

Scott K