Re: opposition against clamav-data in debian volatile
* Henrique de Moraes Holschuh:
> On Sun, 20 Sep 2009, Marc Haber wrote:
>> As long as you do not expect me to manually sign every single upload,
> Why not?
ClamAV, like about every other antivirus scanner, is used to fight
rapidly moving targets. It relies on current -data files to provide any
kind of useful service to its users.
"Malware vs. Anti-Malware: (How) Can We Still Survive?"[1] may give you
a bit of an idea how fast the targets are moving.
I have written and maintained scripts that download signature file
updates for several commercial antivirus scanners and built packages for
them -- which is pretty much the same thing that clamav-getfiles does.
10 updates to the signature files per day are not uncommon in the
proprietary space and I'd be very surprised if things were any different
for ClamAV.
If it's really necessary to generate the signature with manual
intervention, we are going to need a 24/7 commitment by a group of
people to a response time of a few hours or less for every update.
> It is a package, it has root access anywhere it is being installed or
> removed. Even if you abuse the DM machinery to have a key restricted
> to only upload clamav-data, it would still be risky.
There are only a few places from where malicious code could be executed
on behalf of the package creator: The maintainer scripts (preinst,
postinst, prerm, postrm, config) and any executables that may be part of
the package.
The maintainer scripts can be checked and stay constant across new
version, and the list of files shipped in the clamav-data package is
fixed. This stuff can easily be checked automatically between upload and
accepting the package into the archive.
I know that whenever I claim that something should be easy, people tend
to answer "show me the code", so there: If whoever in charge states that
my idea is acceptable, I'll be happy to implement limited checking of
pacakge contents in the archive software.
-Hilko
[1] http://av-test.org/down/papers/2008-02_vb_comment.pdf
Reply to: