b2sum is mentioned twice

[firasuke]

In the comparison section (inside the roadmap) between the tools that toybox provides (and aims to provide) compared to coreutils, I noticed that b2sum is mentioned twice, the first being with square brackets [b2sum] which indicates that you're planning on adding b2sum in the future, and the latter being in the not section which indicates that you're not planning on supporting it, so which one is true?

coreutils: ... [b2sum] [tr] [unexpand] (not: b2sum base32 ...

Thanks for your time and effort.

[landley]

Hadn't particularly decided? Nobody's asked for it yet, I've never used it, no clue what the demand for it is? Not a priority, in any case...

[firasuke]

Well then let me be the first one to ask for it for the sole reason of covering more of coreutils (to me this brings toybox closer to being a decent alternative to coreutils that can build LFS).

I also know a couple of developers who use toybox (and are interested in both BLAKE2 and BLAKE3) and might be interested in seeing this implemented.

[lulcat]

I wrote some alternative in my package manager, in D but I think I also did some kinda porting vs. the coreutils. This also includes b3 which is the default in my distro. (although probably will revert to b2 or sha35).

You can still build LFS perfectly fine without b2sum, in fact, I don't think they have adopted a patch to move from md5sum to b2sum yet in their book(s).

P.S. I recall toybox all those years ago, and just am revisiting. In fact, am just building a LFS now with the tools. Great stuff :) Thanks .Works a treat.

[landley]

I've since bumped into blake2 in the wild at work and will probably eventually implement it. Don't think I've heard of blake3 yet?

[landley]

commit 054d82f

[lulcat]

b2sum runs in constant time as far as I make out here; b3sum is a project some of the b2 gang work on, it has reduced rounds for increased speed but stil considered safe (being closer to the threshold say). Now, at least here no this chip, when I run it, I get slower times than b2 on the first run, but then it gets cached it seems? and is 5-6 times faster. So for reruns of hashing items etc then it's very nice, hands down.

I do however, think I will scale back on the 'being bleeding edge' because regardless of output bits, one is just truncating the 'same string'. Whereas in b2 and sha3 and so on, changing output bits length, changes the overall hash.

This might be a design, the so-called stream ciphers, I don't know , but to me, being old-fashioned, something extra must always have a cost.. so just plonking out as much output bits one likes with no extra effort, doesn't sit well with me :p
So ye, I can point you to some b3sum code else the git page for blake3 has a cargo version.

I am using your toybox at the moment .. fun reminder of how sometimes not all the current stuff in gnu is around but very much fun anyway. Thanks a lot! :) Happy coding.