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