On 05/10/2025 01:32, Collin Funk wrote:
I was looking at changing announce-gen to use SHA-256 and SHA3-256 instead of SHA-1 and SHA-256. That lead me to discovering the following:$ cksum -a sha3 --length=256 --base64 --untagged \ Makefile > Makefile.sum $ cksum -a sha3 --check Makefile.sum cksum: Makefile.sum: no properly formatted checksum lines found The same issue exists for --algorithm=sha2. This patch fixes it: $ ./src/cksum -a sha3 --check Makefile.sum Makefile: OK $ sed 's|[[:graph:]] Makefile$| Makefile|g' \ Makefile.sum > truncated $ ./src/cksum -a sha3 --check truncated cksum: truncated: no properly formatted checksum lines found I left the behavior the same for blake2b since 'b2sum' does not support --base64. I'm not sure if 'cksum -a blake2b' and 'b2sum' should differ in this case...
I just thought of another ambiguous edge case with this, where we have untagged base64 encoded input that happens to be all hex digits. We can't always use the length to distinguish base64 vs hex as: $ cksum -a sha2 -l 384 --base64 --untagged /dev/null | wc -c 76 $ cksum -a sha2 -l 256 --untagged /dev/null | wc -c 76 It's not likely of course, but annoying nonetheless. The same applies to sha3 of course. The same ambiguity applies to '--check -a blake2b' only it could hit in more cases as you can have smaller -l I'm not sure how to handle this apart from requiring length to be specified for --check with untagged input. We should probably document this edge case in the code at least. cheers, Padraig.
