Warner Losh <[email protected]> wrote:
>
> On Wed, Jul 7, 2021 at 12:47 PM Michael Grimm <[email protected]> wrote:
>> Warner Losh <[email protected]> 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
