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

From: Michael Grimm via freebsd-stable <freebsd-stable_at_freebsd.org>
Date: Wed, 7 Jul 2021 20:47:36 +0200
Warner Losh <imp_at_bsdimp.com> wrote:
> On Wed, Jul 7, 2021 at 9:26 AM Michael Grimm <trashcan_at_ellael.org> wrote:
>> Warner Losh <imp_at_bsdimp.com> 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_at_ 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 ;-)

Regards,
Michael
Received on Wed Jul 07 2021 - 18:47:36 UTC

Original text of this message