Created attachment 1358747 [details] problem analysis and a solution hack Description of problem: Running "rkhunter --propupd" reports "... found 137, missing hashes 137". It implies that subsequent rkhunter tests will be compromised. Version-Release number of selected component (if applicable): rkhunter-1.4.4-4.fc27.noarch How reproducible: See above Steps to Reproduce: As root run rkhunter --propupd Actual results: [ Rootkit Hunter version 1.4.4 ] File updated: searched for 174 files, found 137, missing hashes 137 Expected results: [ Rootkit Hunter version 1.4.4 ] File updated: searched for 174 files, found 137 Additional info: See attachment (problem new since upgrade to Fedora 27; implies an incompatibility in the new rpm's or fc27 packaging)
Would you be willing to file this upstream on the rkhunter list? rkhunter-users.net Otherwise I can try and take a look and do so.
(In reply to Kevin Fenzi from comment #1) > Would you be willing to file this upstream on the rkhunter list? > > rkhunter-users.net > > Otherwise I can try and take a look and do so. My issue is that I don't really see it as an rkhunter issue. It happens because the rpm packaging CHANGED between fc26 and fc27. As I don't know HOW the "header tag ARCH" wandered off files and became a package tag (or if rpm just "condenses" it from files into 1 property, or ...?) I would really like it if somebody could figure that point out first. Is it something you can change during the packaging? Is it an error in the current rpm version? Is it Fedora-specific? It doesn't seem to make sense to change rkhunter if there is a bad rpm version out there. Of course if this is a part of rpm flexibility - a feature - then by all means rkhunter should be changed. And yes, my changes are a hack. I should use ${BLA} and instead of "::" there should be a better placeholder and one should first check how many values come for ARCH and the other items and...
Yeah, so this was an intended change in rpm. The fix is just to add = in front of the ARCH querystring to get it to report for each other element of the array. I'll talk to upstream about the fix here and see about pushing out an update. Thanks for the bug report...
(In reply to Kevin Fenzi from comment #3) > Yeah, so this was an intended change in rpm. The fix is just to add = in > front of the ARCH querystring to get it to report for each other element of > the array. > > I'll talk to upstream about the fix here and see about pushing out an > update. > > Thanks for the bug report... Ah. That's interesting. Looking at it I can see the following behaviour: --queryformat '[%{FILEMODES:octal}:...:%{ARCH}:...:%{FILENAMES}\n]' under fc26 delivers value "(none)" for ARCH, but runs under fc27 dies --queryformat '[%{FILEMODES:octal}:...:%{=ARCH}:...:%{FILENAMES}\n]' delivers the proper ARCH under both fc26 and fc27 CAVEAT: --queryformat '[%{=ARCH}\n]' gives a NULL response (no result) while --queryformat '[%{ARCH}\n]' gives a proper ARCH response for both fc26 and fc27 Cheers, George
rkhunter-1.4.4-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-3963fa646c
rkhunter-1.4.4-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3963fa646c
rkhunter-1.4.4-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.