F 1483 : Fix SHA-1 prefix match overwriting SHA-256/384/512 output#216
F 1483 : Fix SHA-1 prefix match overwriting SHA-256/384/512 output#216miyazakh wants to merge 2 commits intowolfSSL:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Fixes an algorithm-selection bug in the CLI hash command where SHA-1 prefix matching could incorrectly override SHA-256/384/512 digest output, and tightens algorithm validation to require exact matches.
Changes:
- Guard SHA-1 selection in
wolfCLU_hash/wolfCLU_hashSetupwithXSTRLEN(alg) == 3so only"sha"maps to SHA-1. - Change hash algorithm validation to exact string matching (
XSTRCMP) to avoid prefix-based acceptance. - Broaden OCSP interop test error-message matching; update
clu_x509_sign.chash-type switch version gating / case handling.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
src/hash/clu_hash.c |
Prevents SHA-1 branch from matching sha256/sha384/sha512 by requiring exact "sha". |
src/hash/clu_hash_setup.c |
Requires exact algorithm match during argument validation and ensures SHA-1 size only applies to "sha". |
tests/ocsp/ocsp-interop-test.sh |
Accepts additional common “file not found” phrasing in Test 6 logs. |
src/x509/clu_x509_sign.c |
Adjusts conditional compilation for unsupported hash-type cases in certificate signing. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
e43bb6a to
1a11f72
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
src/hash/clu_hash_setup.c
Outdated
|
|
||
| #ifndef NO_SHA | ||
| if (XSTRNCMP(alg, "sha", 3) == 0) | ||
| if ((XSTRNCMP(alg, "sha", 3) == 0) && (XSTRLEN(alg) == 3)) |
There was a problem hiding this comment.
Now that exact matching is the goal, consider replacing the XSTRNCMP(..., 3) && XSTRLEN(alg) == 3 pattern with a single exact comparison (e.g., XSTRCMP(alg, \"sha\") == 0). It’s simpler, more readable, and avoids a redundant length check.
| if ((XSTRNCMP(alg, "sha", 3) == 0) && (XSTRLEN(alg) == 3)) | |
| if (XSTRCMP(alg, "sha") == 0) |
src/hash/clu_hash.c
Outdated
| if (ret == WOLFCLU_SUCCESS && XSTRNCMP(alg, "sha", 3) == 0 | ||
| && XSTRLEN(alg) == 3) { |
There was a problem hiding this comment.
Same as in setup: since this branch should only run for the literal algorithm name, prefer an exact compare (e.g., XSTRCMP(alg, \"sha\") == 0) over XSTRNCMP + length guard. This reduces complexity and makes the intent unambiguous.
| if (ret == WOLFCLU_SUCCESS && XSTRNCMP(alg, "sha", 3) == 0 | |
| && XSTRLEN(alg) == 3) { | |
| if (ret == WOLFCLU_SUCCESS && XSTRCMP(alg, "sha") == 0) { |
1a11f72 to
e1ea92c
Compare
dgarske
left a comment
There was a problem hiding this comment.
🐺 Skoll Code Review
Overall recommendation: APPROVE
Findings: 2 total — 2 posted, 0 skipped
Posted findings
- [Medium] Remaining XSTRNCMP calls could be made consistent with the fix —
src/hash/clu_hash.c:104 - [Low] The fix is correct but the if-chain ordering is fragile —
src/hash/clu_hash.c:108-127
Review generated by Skoll via openclaw
| @@ -121,7 +121,7 @@ int wolfCLU_hash(WOLFSSL_BIO* bioIn, WOLFSSL_BIO* bioOut, const char* alg, | |||
| } | |||
There was a problem hiding this comment.
🟡 [Medium] Remaining XSTRNCMP calls could be made consistent with the fix
💡 SUGGEST convention
The PR correctly changes XSTRNCMP(alg, "sha", 3) to XSTRCMP(alg, "sha") to prevent the SHA-1 branch from matching sha256/sha384/sha512. However, other algorithm checks in both wolfCLU_hash() and wolfCLU_hashSetup() still use XSTRNCMP (e.g., XSTRNCMP(alg, "md5", 3) at clu_hash.c:104, XSTRNCMP(alg, "md5", 3) at clu_hash_setup.c:138). While these are functionally safe today because none of those prefixes collide with other algorithm names, wolfCLU_hash() is a public function that accepts alg from external callers (e.g., clu_alg_hash.c). Switching all comparisons to XSTRCMP would be more defensive and consistent with the spirit of this fix — preventing future prefix-collision bugs if new algorithms are added.
Suggestion:
| } | |
| #ifndef NO_MD5 | |
| if (ret == WOLFCLU_SUCCESS && XSTRCMP(alg, "md5") == 0) { | |
| ret = wc_Md5Hash(input, inputSz, output); | |
| } | |
| #endif | |
| /* And similarly for sha256, sha384, sha512, blake2b, base64enc, base64dec | |
| in both clu_hash.c and clu_hash_setup.c */ |
| @@ -121,7 +121,7 @@ int wolfCLU_hash(WOLFSSL_BIO* bioIn, WOLFSSL_BIO* bioOut, const char* alg, | |||
| } | |||
There was a problem hiding this comment.
🔵 [Low] The fix is correct but the if-chain ordering is fragile
🔧 NIT style
In wolfCLU_hash(), all the hash algorithm branches are independent if statements (not else if). With the old XSTRNCMP(alg, "sha", 3) code, if alg was "sha256", both the sha256 branch (line 109) and the sha branch (line 124) would fire because ret was still WOLFCLU_SUCCESS (wc_Sha256Hash returns 0 on success). The SHA-1 branch would overwrite the SHA-256 output with a smaller (20-byte) digest. The fix to use XSTRCMP is correct. As a minor readability note, using else if for this chain would make it obvious that only one branch should ever execute, preventing similar issues in the future. This is not blocking since the fix as-is is correct.
Suggestion:
| } | |
| /* The #ifdef guards make else-if impossible across preprocessor blocks, | |
| so XSTRCMP is the right fix here. No change needed. */ |
Summary
XSTRNCMP(alg, "sha", 3)inwolfCLU_hashandwolfCLU_hashSetupmatched "sha256", "sha384", and "sha512", causing SHA-1 to overwrite
the correct digest and size
XSTRLEN(alg) == 3guard to the SHA-1 branch inclu_hash.candclu_hash_setup.calgCheckloop inclu_hash_setup.cto useXSTRCMPforexact matching instead of prefix matching
Depend on : #211 (Fixed)
Depend on : #219