Dhairya-007 commented on PR #29696: URL: https://github.com/apache/camel/pull/29696#issuecomment-6821234258
Thanks for recomputing the HMACs independently, and both suggestions are in — they make the check better than what I sent. **Raw bytes.** You are right that the round trip was the remaining weak point: `bytes -> String -> bytes` is lossless only for valid UTF-8, and a malformed sequence becomes U+FFFD, so the thing being hashed stops being the thing ClickUp signed. `Utils` now has a `computeMessageHMAC(byte[] message, String key)` overload, the `String` one delegates to it, and `validateMessageSignature` hashes `body.readAllBytes()` directly. The `String` survives only for the debug log and for `InvalidMessageSignatureException`. That also makes the test sharper — there is now a case with a lone `0x80` continuation byte where hashing the raw bytes and hashing the decoded string genuinely differ: ``` raw bytes : 61 80 62 -> 9C41E950B76B9186... round-tripped : 61 EF BF BD 62 -> 8CC3397927DD2889... ``` **Constant-time comparison.** Added, exactly as you wrote it, with `US_ASCII` since both sides are lower-case hex by then. **AssertJ.** Switched — you are right that the rest of the module uses it. **On the default charset.** Agreed that Java 21 makes the original test green either way; it is there to pin the wire behaviour rather than to fail today. The new malformed-UTF-8 case does fail without the raw-bytes change on any JVM, so that part is genuinely covered. **JIRA** — I have no credentials for issues.apache.org from this environment. If you want a `CAMEL-XXXX` reference, could a committer create the ticket (or tell me the number) and I will retitle the PR and amend the commit? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
