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

From: Michael Grimm via freebsd-stable <>
Date: Wed, 07 Jul 2021 18:47:36 UTC
Warner Losh <> wrote:
> On Wed, Jul 7, 2021 at 9:26 AM Michael Grimm <> wrote:
>> Warner Losh <> wrote:

>>> What's the hash that you have at n246157? I think it should be fd5b08977630.
>> No, it's stable/13-n246157-fd5b0897763
>> I will give a n246188+ user land a try, and ...
> Great. Please do let me know... I started this for compatibility so I
> didn't have
> to keep hacking simple scripts for FreeBSD and if something is screwed up
> that means it's falling short of the goal...
>>> So the change is expected, but if the change to all the *sum programs is
>>> incompatible still, I know I'd like to know (as I'm sure se@ would as
>>> well). All the *sum programs are very new and designed to be 100%
>>> compatible with the linux versions and if they aren't that needs to be
>>> fixed.
>> … I will report back.
> Excellent!

I am running stable/13-n246205-9e06b34bb5d, now. 

But I do have to report that rkhunter is still lacking to calculate hashes when using sha256sum instead of sha256.

In a previous mail you wrote: "I recently added the 'sum' variations". 
Does that mean that sha256sum (et al.) didn't exist before? That could explain why rkhunter didn't fail before.

Example output:

	KBN> sha256 crontab.mike 
	SHA256 (test.dat) = 829f9293639f1a590757bf3eaa369c102b071ef450d3f196e29d5c810f23a2c9

	KBN> sha256sum test.dat
	829f9293639f1a590757bf3eaa369c102b071ef450d3f196e29d5c810f23a2c9  test.dat

If I am not mistaken does rkhunter cut that output string into relevant junks. In both cases the hash is at different positions, though ...

> Sorry for any hassle this work is causing.

No big deal for rkhunter, a workaround exists ;-)