On 05/10/2025 21:19, Collin Funk wrote:
Pádraig Brady <[email protected]> writes:
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...
Nice one.
Re blake2b we probably should auto determine digest_hex_bytes
in the base64 case too, so that all length adjustable algorithms
are supported in untagged format. (like b2sum, sha256sum also
does not support --base64).
Sure.
Since blake2b accepts any digest length that is divisible by 8, the
base64 case is a bit trickier. Two different digest lengths can have the
same base64 length, but different amounts of padding. See the following
example:
$ cksum -a blake2b --length 224 --base64 --untagged Makefile
NkhSwK3KuNkA1VSxNKC+gA/LG5GBln6E2AFkpw== Makefile
$ cksum -a blake2b --length 232 --base64 --untagged Makefile
PaS2GwuymJ1Wy5zadJJDUY/uo647qvgm1jvFTiU= Makefile
Since this isn't a regression, but rather an oversight since --base64 was added,
if the blake2b case is addressed, then the NEWS could be generalized to say:
'cksum --check' now supports base64 encoded input in untagged format,
for all length adjustable algorithms (blake2b, sha2, sha3).
[bug introduced in coreutils-9.2]
That works. I thought it was our oversight when adding sha3 and
deprecating sha256, etc. But I guess it always existed for blake2b
before that. The 9.8 release just made the situation a bit worse.
Exactly.
I'd use `tr -d '='` rather than `sed 's|[[:graph:]]...` in the test
as it's more obvious and also I'm not sure how portable the :graph: is.
This doesn't work since not all of the lengths have padding:
$ cksum -a sha2 --l 384 --base64 --untagged Makefile
yTpCxowsARWbP1w+lE6IEsZFx1dJcV9IyvlI+WS6aAj7ahIovM2JWafEQWdGfDi9 Makefile
I assume that the '[[:graph:]]' character class is portable. But
's|[a-zA-Z0-9+/=]...' does fine and avoids character classes.
Oh right. Perhaps a simpler match like 's/. inp$/ inp/' would suffice.
Ok to push in any case.
Otherwise it looks good.
Thanks, v2 attached. I'll push in a bit.
p.s. I notice another edge case with checking untagged base64 format.
Theoretically a base64 checksum could start with SHA256 etc.
which would currently cause cksum to treat it as misformatted line.
I wonder how long it will take someone to run into that situation.
Hah, indeed. I'll have a look at fixing this anyway.
thanks!
Padraig
