* 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org