Bug 174460 - (RootkitHunter128) The version of rkhunter is too old
The version of rkhunter is too old
Product: Fedora
Classification: Fedora
Component: rkhunter (Show other bugs)
noarch Linux
medium Severity medium
: ---
: ---
Assigned To: Greg Houlette
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: FE5Target
  Show dependency treegraph
Reported: 2005-11-29 05:37 EST by Paul Smith
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 1.2.8
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-11 17:40:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul Smith 2005-11-29 05:37:13 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 Firefox/1.0.7

Description of problem:
The current version of rkhunter is the 1.2.7 one. However, 1.1.9-2 is
the one on extras repository. An update would be most welcome!

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.It occurss always
2.It occurss always
3.It occurss always

Additional info:
Comment 1 Greg Houlette 2005-11-29 07:51:00 EST
Yikes!  My apologies.  I have a version of the 1.2.7 RPM that I've got about
6 months runtime on with various systems (RH9-FC3) that I appearantly FORGOT
to get into the pipeline (shakes head in dismay).

I will endeavor to correct this oversight this weekend...

Expect to see an SRPM available for QA by Monday 5 Dec.

Comment 2 Michael Schwendt 2005-11-29 09:10:35 EST
There is no QA process for updates. You can import into Fedora Extras
CVS directly and send it to the build system directly, too.
Comment 3 Greg Houlette 2006-01-05 03:25:16 EST
Again, sorry for the delay.  I've committed the 1,2,7 SRPM to CVS (there is
probably a better way to get it updated in all branches, but for now I just
'brute-forced' it...)  The BOOTSCAN is being re-written to allow for background
execution as a SysV Init procedure that won't hold up the boot process.  It's
not there yet, and as a result this release has the BOOTSCAN removed.  It does
however have auto-update integrated into the CRON scan and much better logging
with Date-stamped output and rotated appended logfiles.  A much simplified
option file in /etc/sysconfig/rkhunter provides detailed diagnostic running at
the 'flip' of a switch...

Should show up in the download repository by weeks end.

Feedback, as always, is welcome...
Comment 4 Michael Schwendt 2006-01-05 06:00:53 EST
Only FC-3, FC-4 and Development are supported at Fedora Extras.
The FC-2 and FC-1 directories have historical reasons only.

You need to use

  Release: 1%{?dist}

in your spec files if you want the same release version for all
branches. The build system replaces the macro with .fc4, .fc3,
and so on. Because else you cannot tag the package revision within
CVS, and the build system will reject your attempt at sending
something to it.

Comment 5 Greg Houlette 2006-01-05 11:44:33 EST
Ahh... are there corrections that need to be made to the repository BESIDES
adding %{?dist} to the .spec file Release: Tag?

I read Tom's guidelines but was under the impression that this was optional, and
I do wish rkhunter to be consistent with Fedora Extras standards.  There may be
a future need to have seperate distribution revisions of the package, though I'm
unaware of such needs currently (though I have not tested on FC4).

What else do I/we need to do in order to fix what I've botched?
Comment 6 Michael Schwendt 2006-01-05 13:01:54 EST
Yes, using the dist tag macro is optional. But still, you need to make
sure that %{version}-%{release} for a package in a newer distribution is
"higher than" (and hence seen as "newer than") version-release of a
package for an older distribution. That means, what is rkhunter-1.2.7-1
for FC3 cannot be rkhunter-1.2.7-1 for FC4, too, but should be
rkhunter-1.2.7-2 or above. Using %{?dist} is a way to work around that
(which is not entirely bullet-proof for distribution upgrades, however,
but that is another story).

Furthermore, "make tag", as needed for "make build" to understand what
you want the build server to build, creates a tag in CVS using the
name/version/release values from your spec file. This CVS tag must be
unique and cannot be shared by multiple branch directories in CVS.


> What else do I/we need to do in order to fix what I've botched?

I haven't seen the diff for this package on fedora-extras-commits list
yet. But I believe you haven't run "make tag" or "make build" yet.
When you do, you will run into problems if you don't use %{?dist}.
Comment 7 Greg Houlette 2006-02-06 06:36:28 EST
Between automobile breakage, computer crashes and personal illness I've had
pretty much nothing but bad luck lately.  In the process of setting up a
'plague' client workstation, my only core 3 machine suffered a major malfunction
leaving me with only a core 1 laptop (which I am unable to install the plague
client on for various reasons).  While I do still have CVS access, I will be
unable to run the tag and build process until I get Core 4 installed on a
repaired/upgraded machine.  I'll see if I can get the time to make the spec file
changes sometime this week...
Comment 8 Greg Houlette 2006-02-21 06:50:13 EST
This is starting to read like a damn blog! O.K... I have resurrected my linux
development workstation on core 4, now fully updated and building and signing
RPMs. Michael has released a new upstream of rkhunter = 1.2.8 which I am now
checking for .spec/patch compatibility.  I still have to get the plague client
and CVS authentication set up (and I am well aware that the core 5 release is
bearing down on us).  This will take at least another week for me to get to...

I'm working it...
Comment 9 Greg Houlette 2006-03-11 17:40:09 EST
The new package version (1.2.8) has been committed to CVS, tagged and submitted
for build in FC-3 and FC-4 flavours.  Again, this release has had the BOOTSCAN
removed.  It's being re-written for background execution during startup.  It does
however have auto-update integrated into the CRON scan and much better logging
with Date-stamped output and rotated appended logfiles.  I did not build a 'devel'
version yet as the upstream signatures database currently only supports FC1-4 and
I don't see a reason to give someone a package that I know is going to cause a lot
of grief due to confusion.

Sorry for taking so loooong...  This will go much smoother next time.
Comment 10 Michael Schwendt 2006-03-11 17:59:57 EST
Don't forget to build for "devel", too, as FC-5 is near.
Comment 11 Greg Houlette 2006-03-12 09:44:37 EST
Tagged and ready...  The problem is that while support for FC5 is simply a
matter of downloading new os.dat, defaulthashes.dat, etc. files, it may take
some time before the signature database entries are added.  During the interim,
the scan will be reporting a 'warning' (Warning: this operating system is not
fully supported!) that not all functions and checks can be performed, because
the system is 'unknown' to the script.  This can be confusing enough to the end
user that it warrants a couple of entries in the FAQ.  I have some concerns
about this...  and what can be done about it before the 20th.

Ideally, as soon as FC-5 goes gold, a new set of database file changes would be
generated and sent to Michael Boelen for use in updating his master set (I don't
have access to another machine that I can install FC-5 on to do this).

I should be doing this as the Fedora port maintainer, but I just don't have the
resources...  any ideas?
Comment 12 Michael Schwendt 2006-03-12 10:30:15 EST
It's just that until the update will be available, Fedora Extras
for FC-5 contains the old build from April 11th 2005,


and people who upgrade from FC-4 will end up with the FC-4 rkhunter
being newer.
Comment 13 Greg Houlette 2006-03-12 15:40:03 EST
Hmmm... Well, faced with the choice of the lesser of two 'evils', I've opted to
go ahead with the devel build for rkhunter 1.2.8 (and hope that it doesn't cause
too much confusion for end users before updated .dat files become available).

I really don't want anyone to continue to use the 1.1.9 package.  It just has
too many shortcomings and is too 'long in the tooth'...

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