On Sun, 20 Sep 2009, Marc Haber wrote: > As long as you do not expect me to manually sign every single upload,
Why not? 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. As you said, you'd have to jump through a lot of loops to do special validation of that specific package before installing it. If it would still address whatever problem space clamav-data wants to fix, maybe it would be easier if you created a package-generator package (that creates a fresh clamav-data package for the user when, e.g. a create-clamav-data command is run). If someone has network access to fetch clamav-data, he also has network access to fetch the signatures, so he could run the "create-clamav-data" utility instead... > It would be massively easier if I knew what are the real issues What jumps immediately to mind is that someone could get a hold of that key, and upload a trojan or bomb that will run as root on anyone that installs (or removes, whatever) the package. > That being said, it looks like volatile's policies are going to change > BIG TIME when it gets integrated into the main archive, and frankly, > as a volatile user, I'd rather see volatile stay separate than seeing > some of its previous principles dumped. Do you have a very secure setup involving two boxes, one of which is fully offline and talks to the first one using a safe, restricted, application layer link to get the clamav data, and upload the finished package back to the first box? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org