coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: cksum --base64/-b support


From: Jim Meyering
Subject: Re: RFC: cksum --base64/-b support
Date: Mon, 30 Jan 2023 22:48:06 -0800

On Mon, Jan 30, 2023 at 11:29 AM Pádraig Brady <P@draigbrady.com> wrote:
> ...

Thanks for the speedy feedback.

> "If must be followed by white space." comment has a typo
> and also not enforced explicitly, so could be removed.

Thanks. Removed.

> valid_digits() may check beyond the end of the buffer
> in the case len != BASE64_LENGTH.

Please share how that could happen.
I don't see how there could be a read-overrun there, since the input
string is always NUL-terminated.
However, I've taking your suggestion below:

> Perhaps change the "else" to "else if (len == digest_hex_bytes)".
> Similarly it may be more defensive / efficient to pass
> digest_len out of split_3().

I'd considered whether to make *split_3 return that length to the
caller, but erred on the side of keeping changes small.
However, given your feedback, I've made both bsd_split_3 and split_3
return digest length via *D_LEN, and thus avoid adding that strlen
call.

> non padded base64 encodings are not supported.
> Is that OK. Worth mentioning in texinfo if so.

IMHO, we must reject a digest that's had any change to its trailing
"=" (padding) bytes.
Done.

> A non padded negative test in cksum-c.sh would be useful.

Good idea.
I've added tests like that in the new test file, removing one or both
"=" bytes in each of those examples.

V2 attached.

Attachment: cu-cksum-base64-v2.diff
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]