On 28/04/2026 18:35, 谢大大 wrote:
Hi,
SM3 is already implemented in gnulib and is used in GNU coreutils as part of
cksum via the --algorithm=sm3 option.
It is a 256-bit cryptographic hash function standardized as GB/T 32905-2016 and
published
as ISO/IEC 10118-3:2018. It's widely used in various applications, including in
TPM 2.0 and the
Chinese commercial cryptography suite (where SM2 signatures often pair with SM3
hashing).
We already ship an SM3 implementation in GNU coreutils as part of cksum via the
--algorithm=sm3 option,
so, the hash logic is already in the tree. What's missing is the conventional
standalone interface that users expect.
I'd like to propose adding sm3sum as a standalone utility that behaves
identically to sha256sum:
it would print or check SM3 checksums, support -c/--check for verifying
checksum files, support --tag for BSD-style output,
support -z/--zero for NUL-delimited output, and understand the standard
--ignore-missing, --quiet, --status, --strict, and --warn flags.
It would be integrated via --help and info documentation and be a symlink or
hardlink to the same multi-call binary as the other digest tools
(just like sha256sum, sha512sum, b2sum, etc. are today).
There are several reasons this makes sense. Precedent: every other hash
algorithm supported by cksum --algorithm that has a matching
standalone tool (MD5, SHA-1, SHA-2 family, BLAKE2) already exposes the
standalone *sum interface, so SM3 is the natural missing piece.
Discoverability and usability: users familiar with md5sum or sha256sum expect
to find sm3sum on their PATH. While cksum --algorithm=sm3 works,
it's far less discoverable and breaks muscle memory. Implementation cost is low
because the SM3 digest implementation
already lives under lib/ and src/digest.c; adding the new command is largely a
matter of wiring up the plumbing and updating the build system.
Finally, there's a practical formatting issue:
cksum --algorithm=sm3 outputs lines like "SM3 (foo) =
1c6d3bac5d1f487f90dfd880ac5b2eb5ee7801e28927786ff7104ba2da28f9ba",
but the conventional *sum tools (and the sm3sums.txt files people expect) use
the format
"1c6d3bac5d1f487f90dfd880ac5b2eb5ee7801e28927786ff7104ba2da28f9ba foo".
Generating sm3sums.txt from cksum's output requires extra post‑processing like
command sed 's/^SM3 (\([^)]*\)) = \(.*\)$/\2 \1/' ,
so having a dedicated sm3sum would output the expected format directly.
The change would be purely incremental: NO new dependencies (SM3 code is
already compiled into the cksum binary), NO impact on existing commands.
Test coverage would follow the pattern of existing *sum tests.
I'm happy to prepare and submit an implementation patch if there is interest.
Feedback and suggestions are welcome.
We're not adding new commands for future hash algorithms.
This is not sustainable going forward.
For e.g. there is also no corresponding utility for cksum -a sha3
From the documentation:
"""
‘cksum’ is the preferred interface to these digests,subsuming the other
standalone checksumming utilities, which can be
emulated using e.g. ‘cksum -a md5 --untagged "$@"’
"""
So you could create a script called sm3sum containing:
#!/bin/sh
exec cksum -a sm3 --untagged "$@"
cheers,
Padraig
