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. Thanks, Tim Xie
