[Pkg-clamav-devel] The future of clamav wrt. stable/volatile

[aCaB]

On Thu, Jan 29, 2009 at 07:01:38PM +0000, Stephen Gran wrote:
> This one time, at band camp, Philipp Kern said:
> > On Wed, Jan 28, 2009 at 05:50:19PM -0500, Scott Kitterman wrote:
> > > I maintain klamav.  As I understand it, DM's don't have upload rights to 
> > > volatile.  I don't really have time to deal with sponsorship hassles 
> > > currently, so I'd probably orphan the package.
> > 
> > So clamav is not sufficently modular to separate the library and the scan
> > engines?  Ho hum.
> 
> No, or at least not yet.  There are two basic issues that can't be
> addressed with signature updates: support for new unpackers, and support
> for new signature types.  I'm hoping once upstream gets support for all
> of the more common unpackers, things will settle down a bit, since the
> need to update signature types is less common.

Hi,
I've been silently watching this thread for a while.
Unfortunately I don't have much to add.
Effective malware scanners belong to volatile, there should be no doubt
about that. Even with the relativly short life cycle of etch we've ended
up with a version of clamav in stable, which, basically, doesn't catch
sh*t.

The other question being asked is whether it makes sense to keep 3rd
party tools which link libclamav under stable. And that's not an easy
question at all...
Starting from 0.95 we will see the very first attempt to stabilize the
API/ABI (which historically has been a total disaster). Additionally, a
sane set of default options will be employed for all those tools which
are too old to be aware of more recent changes.
However clamav is, in this regard, a very atipical project in that it
lacks an ultimate development roadmap (or it has got very fast
changing goals if you prefer).
For example around 3 years ago a new functionality was added to detect
phishing emails. The initial reaction was very mixed and was seen by
many users as something outside the traditional scope of an AV.
More recently a new experimental feature for data leak
detection/prevention was added.
In such cases, picking up reasonable defaults is not very easy.

In my opinion all the programs with the ability to talk to clamd (or to
invoke clamscan/clamdscan) can be safely left under stable. The user has
still got the ability to use an updated clamav from volatile with no
problems at all.
On the other hand, programs which can only link libclamav should be
divided into two categories: real-life tools and other tools.
In the the first set are all those things which are designed to scan
live malware, like mail or web scanners. These should preferably go to
volatile.
The second group contains all the rest, which is basically GUIs, offline
file system scanners, and the like. Leaving these under stable is
probably fair enough.

Just my 2 eurocents,

-acab