md5ums: Why tripwire etc is no solution
1. There is a time between the installation of the package and the run
of any tool to generate checksums. Things can happen to a file in that
time period. Files can even be damaged while being installed by
dpkg. One example is a broken hardware writing faulty data to the HD
on occasion. Or some breakage in system software etc.
There are certainly other scenarios that one can envisioning to cause
file changes between the time the package is generated on the
maintainers machine at the running of tripwire after the install.
md5sums does not have this window of opportunity for file corruption.
Tipwire etc can not guarantee that the files are the same as packages
on the *maintainers* system.
2. Tripwire needs to be rerun after a package is installed, removed or
changed in any way. Needless to say that this is quite a hassle and
takes awhile. The user can easily just forget it doing it after an
update of a package. Running tripwire in such
a situation will show strange results that might not be easily
comprehendable by an average user.
With md5sums reruns are not necessary and handling can be
made user friendly and easily understandable.
3. Very importantly md5sums covers the integrity of binary files
installed. Corruption in config files is usually visible since config
files are mostly designed to be readable by humans. The configuration
of a malfunctioning package can be checked with an editor. The
binaries of such a package can be checked with md5sums.
Reply to: