Date: Wed, 7 Jul 2021 20:47:36 +0200 From: Michael Grimm via freebsd-stable <freebsd-stable@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, FreeBSD ports <freebsd-ports@freebsd.org>, lukasz@wasikowski.net, Stefan Esser <se@freebsd.org> Subject: Re: security/rkhunter without hashes after recent STABLE-13 update Message-ID: <08637D0D-9D65-4F53-9A64-F4742BA8E415@ellael.org> In-Reply-To: <CANCZdfojJ%2BiG9dcZ=nPZ65qsON6v2rnG6PLQwQFMJ0N-U8bohQ@mail.gmail.com> References: <416D3033-138D-4BBB-84FA-FAEA2944C837@ellael.org> <CANCZdfr3Ye2hbZJtvBmYqKMF9S_KbGHCzsoRWbMjCxwPEOJSkQ@mail.gmail.com> <B829235A-3C8F-46F4-8D25-00A6125CE264@ellael.org> <CANCZdfojJ%2BiG9dcZ=nPZ65qsON6v2rnG6PLQwQFMJ0N-U8bohQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >>=20 >> No, it's stable/13-n246157-fd5b0897763 >>=20 >> I will give a n246188+ user land a try, and ... >=20 > 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... >=20 >>> 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. >>=20 >> =E2=80=A6 I will report back. >=20 > Excellent! I am running stable/13-n246205-9e06b34bb5d, now.=20 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".=20= 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=20 SHA256 (test.dat) =3D = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?08637D0D-9D65-4F53-9A64-F4742BA8E415>