GCC 12's -Wstringop-overflow flags issues in SHA224_Final, etc., because it calls into generic code that might output a SHA-224 length or a SHA-256 length, and the function prototype declares the array is only sized for SHA-224. This is a bit messy because OpenSSL's API for the truncated SHA-2 hashes allows you to mix and match them. The output size is set by SHA224_Init and then, originally, SHA256_Final and SHA224_Final were the same thing. See how OpenSSL's own SHA224 function calls SHA224_Init + SHA256_Final: https://github.com/openssl/openssl/blob/OpenSSL_1_1_1q/crypto/sha/sha256.c#L49-L61 To get the function prototype bounds to work out, we tightened this slightly in https://boringssl-review.googlesource.com/c/boringssl/+/47807 and added an assert to SHA224_Final that ctx->md_len was the right size. SHA256_Final does not have that assert yet. The assert says that mixing SHA256_Init and SHA224_Final is a caller error. This isn't good enough for GCC 12, which checks bounds assuming there is no external invariant on ctx->md_len. This CL changes the behavior of the shorter Final functions: they will now always output the length implied by the function name. ctx->md_len only figures into an assert() call. As we don't have the assert in the untruncated functions yet, I've preserved their behavior, but the test run with cl/471617180 should tell us whether apply this to all functions is feasible. Update-Note: Truncated SHA-2 Final functions change behavior slightly, but anyone affected by this behavior change would already have tripped an assert() in debug builds. Change-Id: I80fdcbe6ad76bc8713c0f2de329b958a2b35e8ae Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54246 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>chromium-5359
parent
19009c51bf
commit
2749466282
2 changed files with 19 additions and 19 deletions
Loading…
Reference in new issue