ClamAV-Daemon Out of date

this is a recurrent ubuntu problem, why not backport from edgy?

clamav-0.88.2 is affected by a security problem too:

http://www.securityfocus.com/bid/19381

Well, now there's 0.88.4 in Edgy. I think we should make a dapper-security update for this, since clamav is a pretty commonly used package on the server.

Yes , please. Make a dapper-security update, an alternative source package ala debian-volatile or something. This is essential on my mail servers.

Hi!

The security fix from 0.88.4 has now been backported to the Dapper 0.88.2 version. Also, since edgy has 0.88.4, would it be correct to say this bug report is solved?

Clamav is an essential package for mailservers, as John Dong suggested, dapper should have the latest and greatest release, since there is no 'volatile' for ubuntu probably dapper-backports is the way to go.

since the actual version of CLAMV is 0.88.5, I'd say it is not completely solved. ;)

I'd prefer if at least the binaries would be available earlier...
I installed 0.88.4 on Oct. 12, (0.88.3 was completely skipped!) and just FOUR days later (Oct. 16) this version was outdated again!

Not a good quota for a security product... :(

0.88.5 just came out. It'd be nice to have the security fixes backported to Dapper and Edgy, which will probably happen (I'm not the security guy around here :D)

The changes from 0.88.5 were already backported. :) See bug 66510.

If you are backporting changes, why don't you change the check for the version to check the version with apt rather than its current check? If Ubuntu admins can not trust their software to not give erroneous security errors they will:

1. Start ignoring all security warnings.
2. Have no ability to properly determine their security readiness.

This is an issue about empowering the users to see and do the right thing.

As of today (2007 :) we have:
clamav-0.88.2 in dapper (functionality level = 8)
clamav-0.88.4 in dapper-backports and edgy (functionality level = 8)
clamav-0.88.7 in feisty (latest stable from upstream. I think func.level should be 10)

required functionality level as of today is 10

This means (http://www.clamav.net/faq.html#pagestart) that dapper[-backports] and edgy are not able to use all the signatures in the database, and this in turn means that it's nearly useless as an antivirus system (for e.g., a mail server).
Backporting security fixes in the engine does not make it understand newer signatures that require higher functionality levels.

The frequency of updates to clamav and its backports should be improved, IMHO, and we already have the package in feisty so it should be an easy job.

Indeed, I'm using CLAMAV as an in-transit-mailscanner (AMAVISD) and also for regular probing the user-home-directories.

This is getting more and more useless!

CLAMAV should get more importance as it seems to be the only antivirus-solution to be installed automatically...?
May be it can get a separate "updater" using the sources from www.clamav.net and recompiling in case of this "out of date"-error?

The problem has come up again in 6.10, can you please update to 0.88.7?

I am currently struggling with the same issue.

As of Jan 29, 2007 this is still a problem in 6.06, and 6.10

WARNING: Local version: 0.88.4 Recommended version: 0.88.7

We have several locations using *nix of various flavors for our firewall, email, and proxy solutions, and are in the process of moving all of the systems to 6.06LTS and Bsd. This should ease our administrative burden, and make my life simpler.
 However, the lack of an up-to date package for Clamav means that we are going to have to use debian sid instead.

This problem has been in launchpad for 6 months, and has already been corrected upstream.

Debian now includes clamav in the Volatile repo.

This is not a minor problem, and needs to be addressed in some fashion. A server-os isn't much use without a working antivirus solution, as mail-servers, samba/nfs servers, proxy servers, and firewalls all need some type of antivirus software in order to be effective.

Agreed, put me down for this affecting our servers too.

We're still at 0.88.4 in dapper / edgy.

As time passes by this 'old' clamav becomes more and more useless as an effective antivirus.

Can you guys please backport 0.90 from feisty?

Clam 0.90 cannot be safely backported to a 0.8x system, as it has an API change and requires rebuilding of any clamav dependent applications.

But - what do we do about that then ?
Secutiry is definitly a concern on production systems - and as I remember - dapper is also used for 6.06.1 LTS - which tells Long time support. This also means - that all systems out there building up on that version will have restricted security if the Admins are not able to fix that ...

IMHO - even if we do have an issue because of a changed API - this doesn't give us an excuse to concern on a package - that is really security focused. In that case we should really consider adapting all packages linked to clamav...

Why do we have the dependency checkings in debian packages for anyway ?
To make sure dependencies are matched correctly...

I really opt for updated packages...

Anyone has a diff between both API's ? Would be interesting to see what changed...
Maybe it's backwards compatible ...

The importance of this bug has been "undecided" for ages, IT IS a critical one for server usage

Another question - anyone made some ubuntu packages ???
or has a repository that can be used ?
It is IMHO (coming from me - 14 Years in Internet Security Business) a very critical issue. I don't mind having that system in place... cause I know my systems.
But loads of People rely on us (Ubuntu) to make their Systems secure...

And here - with this attitude - we fail...

Of course not, that's why this bug is still open...
May be "LTS" means "Long Time Stay" (with old software)?

It's a shame.

You guys Think we could start a petition ? or a Vote ? to get this issue addressed ?
Of - who can we send an E-Mail to try to get that done ... to try to discuss this matter ?

Anyone knows how to retrieve a list of applications that are dependent on this ?

All we need then is to validate these apps against the new version of clamav and make sure all apps that are on a system get updated clean.

Damn - we need to do something about that ...

The things that are critical for clamav are:

Virus definitions - these are updated through freshclam.
Security fixes - these are being updated through the security updates. Since clamav is in Universe the fact that you are getting the security fixes goes beyond what Ubuntu has promised to do.

So, you are getting what you need in a stable release and, as is appropriate, no more. I think what you need to do is quit over-reacting to log messages.

Well - from the standard/stable-view prespective - yes. However - just testing both setups - version 0.90 catches about 1 virus more out of 10 - which for me - is a valid reason to use the new version.
I don't care for myself - as I have the knowledge to build myself new packages - how about the other Users out there - not having a clue what a Unix system is - and using ubuntu ???

I just invested several hours investigating what it would take to backport the current 0.90.1 version from Feisty to Edgy and Dapper. The bottom line is that there are incompatibilities between 0.90.1 and programs that depend on clamav (I tested Klamav on Dapper). While it appears that clamav-daemon would work ok, there is no way to backport just part of a package.

To quote from the current backport policy, "Backports should not interfere with existing packages. For example, introducing a new version of a library or language stack that renders some existing packages incompatible is generally not acceptable." See https://wiki.ubuntu.com/BackportRequestProcess. It looks like backporting is not possible.

Scott, you're right waying that we get what we're supposed to get from a stable release, that's why I was asking for a backport in the first place :)

Regarding the problems with backporting, thank you for your work looking into it. In this situation I think we should consider the problem as being upstream, since clamav developing is forcing users to switch to the new API to get the updated engine. Sad but true?

Anyway, I agree it's not an ubuntu packages problem any more. Maybe we should ask upstream to backport the new engine to a 0.8x release compatible with the established API, and then an upgrade in dapper's clamav package would be possible and make sense. We still have some *years* of 'LTS' left to use dapper :)

Unfortunately that would present a different policy problem. Per the backports policy, backports have to come out of the developmental release. Since Feisty (and gutsy) are already on 0.90.2, I'm not sure how that could be supported.

I think that there is a policy issue that needs to be sorted because for an application like clamav, stability is not the primary/sole goal. I think that clamav needs some kind of special treatment.

Gents, the only Open Source Anti Virus Scanner is complete out of date on a system with "LTS". Is this the policy ....?

We've been working on a solution to this problem. The problem is that the newer clamav breaks all kinds of things that depend on it.

No easy or good solution. Don't be stunned if the subscribers to this bug get asked to help test stuff. That's going to be the most difficult part to get done.

well, if it's not too complicated to do so, AND if one can always revert to the latest working stable in case of troubles, you can count me in.

We should really try to sort this out, and not just to have a good solution on dapper but also to prevent problems like this from happening again (what if clamav 1.00 breaks API with 0.90 while 0.90 is in the next 'LTS'?). Also, I think a problem like this could arise for other packages as well.

I'm already using lots of virtual machines (xen domU) with dapper, so count on me for whatever testing is needed. It takes me 5 minutes to bring up a new dapper system, install, test, delete the system :)

So, if I understood correctly, this is our situation:
- some form of upgrade to clamav in Dapper is really desired and also coherent with the 'LTS' / 'server' release idea.
- can't backport from more recent versions of clamav (which we have in more recent versions of ubuntu) since it changed API. This is against backport policy rule 3 ('New versions can be backported, when they're already compatible with OS and system-relevant libraries.'), rule 4 ('No new libraries which will "break" or affect other applications (e.g. libvorbis, libz, etc.) unless the update fixes an exploit.') and also against good, common sense.
- can't backport from an hypotetical 0.80.x branch with newer scanning engine since we don't have a port to backport from - see backport policy rule 1 ('Only packages currently in Ubuntu's development branches are eligible for backporting').

I'm assuming the official policy is the one at https://help.ubuntu.com/community/UbuntuBackports. Possible solutions:
 * find a way to backport a 0.90.x version and make it coexist with the current system.
Eg., call it clamav090 so apps that use 'clamav' do not get disturbed - or whatever (portage slots come in handy in this kind of situations on gentoo. don't know if the portage guys found a way to make clamav 0.80.x and 0.90.x coexist as two different slots, maybe it's worth a look). This way we could have the desired scanning engine on the system, to be used through clamd or similar interfaces (that do not suffer the API change problem). I don't know if this is acceptable with ubuntu policies and/or actually possible to do.
 * get the new scanning engine on 0.80.x, get the new 0.80.x in a in-development ubuntu (same problems as previous case to make 0.80 and 0.90 coexist since we have 0.90 in newer versions of ubuntu) and backport. Apps on newer ubuntu will link (and depend) on 0.90.x and apps on dapper link (and depend) on 0.80.x, so they'll just ignore the backport while anything that dosn't suffer the API problem will be able to use it (basically anything the interfaces to clam through one of its processes and not through calls to its libs).
 * get the new scanning engine on 0.80.x and find a way to put it in dapper without putting it in newer ubuntu releases. No issues with 0.80 and 0.90 on the same system, but we need to change backports policy or find an acceptable trick to get around it.

What do you guys think? Is any one of those possible and worth trying? Do you have any other solution to propose?

Some final points I'd like to stress:
- this is really a critical problem with clamav on dapper
- this could apply to later releases of ubuntu (see the clamav 0.90 -> 1.00 example in the be...

That's all well thought out. We recently picked option 4:

Test all the Dapper packages that depend on clamav with the current clamav and backport all the ones that break with the new clamav with or before a clamav backport.

This will take some doing. I've established a team to work on this. You can join at:

https://launchpad.net/~ubuntu-clamav

The status of testing and locations of update clamav package for testing are at:

https://wiki.ubuntu.com/MOTU/Clamav

If you can test something, let us know what you are working on on the wiki.

Since all of this will take a while, I am also preparing a source backport of clamav 0.88.7 (the last easily backportable version that was in an Ubuntu repository). I expect that within a week or so.