Sam writes:
> Anti-trojan against the executable binaries themselves.
That's security through obscurity. The more people know about it, the
more useless it is. There are many other places for an intruder to hide.
(The best I've seen in actual use was buried inside a user's cron file.)
> RPM will actually tell you if a given configuration file does not
> match the one that was shipped with the package.
So, every time you do this (after shutting down your system and booting
from a safe floppy), you learn that /etc/aliases and /etc/aliases.db and
/etc/sendmail.cf and your .login and many other files have been changed.
Do you now go through all those files manually, praying that you don't
miss any clever little changes? How do you handle /etc/aliases.db?
> If you need to be certain that your configuration files to be untainted,
> simply apply site-specific changes during the installation process, before
> you wrap the RPM,
Obviously you can make your own backups. This works for /etc/aliases.db
(if you don't change it too often); it also works for the qmail files.
> > Why can't you do exactly the same thing for qmail?
> I certainly can. Except that I won't be able, officially, to redistribute
> my altered Qmail package.
You simply have to follow the var-qmail rules, to guarantee
compatibility. See http://pobox.com/~djb/qmail/dist.html.
> I do recall reading somewhere that traditionally /var is supposed to be
> the place where you should keep stuff that's constantly changing.
Sun invented /var as a place for machine-specific files that wouldn't
fit into /etc. Change speed is irrelevant; there are files in /etc that
change frequently, and files in /var that don't.
> I cannot make assumptions about what userids are available, and I
> would like my package to be installable on every system.
See http://pobox.com/~djb/qmail/var-qmail.html.
> As a result, the mechanisms I have in place for verifying
> the integrity of the package installation will not work.
They don't work for sendmail's /etc/aliases.db either.
---Dan
