Make b2sum part of libb2

[przemoc]

b2sum may be added as an example of library usage, i.e. not built by default unless explicitly asked (e.g. make b2sum). This repository should then become the canonical location of b2sum.

If you don't like this idea, then please consider putting b2sum in its own repository, most likely BLAKE2/b2sum. Having it in BLAKE2/BLAKE2 may work for BLAKE2 reference material, but doesn't really work for distributions and package maintainers. If you'll decide to create such repo, don't forget about release management for it too (tags, tarballs, etc.).

It will substantially help in greater adoption of this utility.

[sneves]

There's a confounder here, which is that b2sum already exists in coreutils, though there it is limited to blake2b only. I'm not sure having two b2sums is a good idea.

[przemoc]

b2sum existing also in GNU core utilities is not a problem. coreutils is a popular set of small programs, but not universally used, often not in embedded solutions for instance. I think it would be a bit unfortunate if canonical b2sum location would be in package of utilities that prospective b2sum users may not be interested in.

Second thing you already mentioned yourself: GNU-ized (thankfully not in the license) b2sum has hardcoded choice about BLAKE2 variant used (BLAKE2b, which is partially explained in introductory commit ea94589e9ef02624a3837f97f80efd7d3dcf56bf), and made 512-bit a default digest length (not hardcoded though). It kind of makes sense at first sight if you want b2sum to be similar to other *sum utilities, but not really if you think it through, because if such utility was meant to cover one BLAKE2 variant, it should be really one variant including digest length, and therefore it should be named b2b512sum, just like there are sha256sum or sha512sum. It's very unfortunate that it was decided within coreutils to strip functionality of original b2sum, yet stick to the original name.

b2sum should really remain multi-variant tool, but it could be extended to additionally choose appropriate variant in automatic way depending on the name of executable that is used to run it:

• b2b512sum - BLAKE2b 512-bit
• b2b256sum - BLAKE2b 256-bit
• b2s256sum - BLAKE2s 256-bit
• b2b128sum - BLAKE2b 128-bit
• b2s128sum - BLAKE2b 128-bit
• ...

Bunch of cheap symlinks and all the variants+sizes are covered, if desired, but I possibly wouldn't go below 64-bit sizes.

---

If you're somewhat concerned about possibility that coreutils' version of b2sum became de facto standard (I don't think it's really true, but maybe I'm biased), I think it could be named b2xsum here, which kind of fits for obvious reason.

If you'd be okay with bringing b2sum to libb2, be it as b2sum or renamed to b2xsum, I'll happily help you with all that, but didn't want to do it and ask later (or create new repo with b2sum, if the situation can most likely be improved directly at the upstream).

Once again, I'm not saying to make b2sum being built by default next to libb2, but only if requested. After all it's one of the best possible examples of libb2 usage.

---

EDIT (2018-02-15T22:08Z):

Ok, I honestly forgot about BLAKE2bp and BLAKE2sp variants, but they could have their own symlinks too, of course.

I also forgot about BLAKE2x, and some could argue that because libb2 doesn't implement it, b2xsum could be misleading (if renaming option would be chosen). I don't think it would be a real issue, though, and BLAKE2x support in libb2 may always show up in the future.