I use tripwire, but every time I install updates of packages with a large number of files, such as glibc or the kernel, it becomes pretty much impossible to verify that no files have been unintentionally (or maliciously) modified just as I installed the updates. And, unfortunately, it's not that unlikely to have an intruder get in just as you install the package that fixes that very security problem (assuming you always install fixes as they are published, which I do). It would be nice to have some integration between RPM and tripwire, such that I could run soem RPM command that would run `tripwire -m c -I' with an editor that will look at log of modified files, compare their md5sums and timestamps with those in the RPM database and approve the changes, leaving any other modified files alone. It would be nice if it would display the list of installed/uninstalled packages before committing the changes. Extra points if this could somehow be integrated into RHN, so that one didn't have to go into every single machine of a workgroup after requesting a global update.
If the RFE gets into rpm, then python bindings are the only impediment to using in up2date. Whether RHN chooses to do that is a different matter ... Thanks for entering the bug report.
Re-implementing tripwire within rpm looks very doable, will probably take a shot at an implementation this summer ...
FYI: rpm-4.1-0.53 and later now verifies header/digests/signatures whenever a header is read. AFAICT There are 3 things that remain to duplicate tripwire functionality on top of an rpm database: a) (easy) sign all the database files in order to detect any modification. b) (moderate) steal a tripwire configuration paradigm, remapping duplicated functionality onto existing verify CLI bits. c) (moderate) walk the file tree to find files not under package management, and %ghost those files into a separate, virtual package header.
This ain't gonna happen for rpm-4.1, will be addressed in rpm-4.2
*** This bug has been marked as a duplicate of 76877 ***