Dan's points on this issue, as usual, are good ones. If you're checking
file consistency against known-good read-only copies, failing to verify
binary files generated from human-editable configuration files on the
system (various qmail cdbs, alias.db, the passwd dbms on the various
*BSDs, etc) is nearly as bad as not doing the check at all.
The primary contention of the Redhat binary image verification camp is
that the qmail binaries resist the only verification method available in
the Redhat system: comparisons of checksums of the files on disk versus
checksums stored on the read-only media. This strikes me as more of a flaw
in the Redhat binary verification system than in qmail -- it would not be
difficult to come up with a script that would perform the install-time
operations on the qmail binaries from the CD-ROM (uid insertion), and
then compare the checksum of the freshly generated binaries against the
on-disk binaries.
Some partisans may decry, "Why should some customized package-specific
binary comparison method be included in the binary verification system,
instead of the author compromising his design principles because we
yelled at him loud enough?" I agree with them completely, on the former
issue. :)
There's no sense in modifying the Redhat binary verification system to
understand the magic necessary to verify qmail binaries. However, adding
a generic per-package verification hook would make a great deal of sense;
rather than (or in addition to) the checksum verification, each package
can provide a /bin/sh script that knows how the details of verifying
files under its aegis that may resist checksum verification, for whatever
reason. In the qmail package, this script would copy the qmail binaries
from the CD-ROM, insert the uids, and then compare the on-disk binaries
against the freshly-generated binaries. If a discrepancy was noted,
an error message could be printed, and the script would return with a
non-zero exit code to the installer, which could then act as it saw fit.
The addition of a package-specific verification hook would greatly expand
the flexibility and reach of the binary verification system. The sendmail
package could generate a new /etc/aliases.db from /etc/aliases, and
compare it against the on-disk copy, for instance. :) Note that I do
not suggest that use of this hook be manditory -- if a package
is such that it can be verified by checksums alone, there is certainly
no reason to require any custom script be provided.
I'll leave you with this: there should be less enthusiasm for modification
of the package to fit within the distribution framework, and more
interest in modifying the capabilities of the distribution framework
to handle packages with unusual requirements. I doubt that qmail will
be the last package to present a challenge to a package-manager format;
adding generic hooks and flexibility now will make the next occurrence
much less frustrating and time-consuming for all involved. :)
But this is only marginally relevant to the qmail list, so I'll stop here.
Besides, I have an early start tomorrow for holiday travel; happy, safe,
and enjoyable holidays to everyone. :)
--
shame is no weapon against the shameless. -- john perry barlow
[EMAIL PROTECTED] (michael handler)
