Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 58910 - [4.2]: feeding RPM update info to tripwire
Summary: [4.2]: feeding RPM update info to tripwire
Status: CLOSED DUPLICATE of bug 76877
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 7.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-01-27 19:15 UTC by Alexandre Oliva
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2002-11-16 20:31:07 UTC

Attachments (Terms of Use)

Description Alexandre Oliva 2002-01-27 19:15:09 UTC
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.

Comment 1 Jeff Johnson 2002-01-27 19:28:35 UTC
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.

Comment 2 Jeff Johnson 2002-03-18 17:03:02 UTC
Re-implementing tripwire within rpm looks very doable,
will probably take a shot at an implementation this summer ...

Comment 3 Jeff Johnson 2002-07-24 19:13:48 UTC
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.

Comment 4 Jeff Johnson 2002-07-25 12:31:29 UTC
This ain't gonna happen for rpm-4.1, will be addressed in rpm-4.2

Comment 5 Jeff Johnson 2002-11-16 20:32:51 UTC

*** This bug has been marked as a duplicate of 76877 ***

Note You need to log in before you can comment on or make changes to this bug.