Re: opposition against clamav-data in debian volatile
2009/9/20 Henrique de Moraes Holschuh <hmh@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.
Reply to: