Re: security/rkhunter without hashes after recent STABLE-13 update

Warner Losh <imp@bsdimp.com> wrote:
> 
> On Wed, Jul 7, 2021 at 12:47 PM Michael Grimm <trashcan@ellael.org> wrote:
>> Warner Losh <imp@bsdimp.com> wrote:

>>> Sorry for any hassle this work is causing.
>> 
>> No big deal for rkhunter, a workaround exists ;-)
> 
> I think the reason is that it automatically switched to using sha256sum
> because it was present, but it didn't automatically change #HASH_FLD_IDX=4
> to be 1. The shell script is tricky enough that I've not looked through it
> all. I'd argue this is a bug in the get_sha_hash_function which doesn't
> adjust the HASH_FLD_IDX based on which version it finds. Instead, it sets
> it unconditionally to 4 on *BSD or DragonFly.
> 
> Warner
> 
> P.S. I think it needs something like the following updated
> patch-files_rkhunter and/or changes upstream. I don't know what this port
> does, apart from what I've just read. Can you see if this fixes this?


Your rkhunter script seems to be different to mine …

	MWN> patch < rkhunter.diff 
	Hmm...  Looks like a unified diff to me…
	The text leading up to this was:
	—————————————
	|--- files/rkhunter.orig	2018-02-24 16:08:27.000000000 -0700
	|+++ files/rkhunter	2021-07-07 13:38:56.094378000 -0600
	—————————————
	Patching file rkhunter using Plan A…
	Hunk #1 succeeded at 4751.
	Hunk #2 failed at 7525.
	Hunk #3 succeeded at 19734 (offset 3 lines).
	Hunk #4 failed at 19810.
	2 out of 4 hunks failed--saving rejects to rkhunter.rej
	done

But anyway, you nailed it! That fixes rkhunter. It will now produce hashes for both /sbin/sha256 and /sbin/sha256sum.

The attached patch (diff to new rkhunter script with both succeeding hunks) will work for the rkhunter-1.4.6 script.

Thanks and with kind regards,
Michael