Re: security/rkhunter without hashes after recent STABLE-13 update
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 07 Jul 2021 18:47:36 UTC
Warner Losh <imp@bsdimp.com> wrote: > On Wed, Jul 7, 2021 at 9:26 AM Michael Grimm <trashcan@ellael.org> wrote: >> Warner Losh <imp@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@ 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