2009/9/20 Henrique de Moraes Holschuh <h...@debian.org>: > 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.
This really sounds like there is a "use case" for data-only "packages" that: - do not include maintainer scripts (dpkg refuses to run them) or are only allowed a set of limited tasks (run in a restricted shell or with reduced privileges) - are only allowed to write in a specific place on disk (such as /var/lib/<packagename>) Wouldn't that reduce the problems surrounding clamav-data and other frequently-updated data packages? <long-shot>Maybe that's something that could be taken on board by dpkg maintainers?</long-shot> As (co-)maintainer of other security software which relies on frequent data updates (Snort, Nessus/OpenVAS), I believe that most admins and users now understand that for software to be effective the associated security data provided in packages (such as that used by ClamAV, Snort or Nessus/OpenVAS) requires an Internet connection. And frequent updates are needed through the use of upstream's custom services and tools. IMHO data packages for this kind of software should be used only to provide way for users to have a limited feature-set so that the software isn't inmediatley useless after installation if they don't have an Internet connection readily available. Of course, in this case, users should always be warned/encouraged to update as soon as the package is downloaded if used in production environment. However, the data package provides an easy way to test if the software meets the admin/user's requirements before he introduces the changes required in the environment [1] to support the software use in the long run. Regards Javier [1] Typically direct connection to the Internet or proxy reconfiguration. This is true in many organisational's internal network environments in which direct Internet access can not be taken for granted. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
