Dhairya-007 opened a new pull request, #29696:
URL: https://github.com/apache/camel/pull/29696
## Problem
Both ends of the ClickUp webhook signature check depend on the JVM's default
charset.
`ClickUpWebhookService` decodes the request body with it:
```java
try (InputStream body = message.getBody(InputStream.class)) {
messageBody = new String(body.readAllBytes());
```
and `Utils.computeMessageHMAC` encodes the message and the key with it again:
```java
mac.init(new SecretKeySpec(key.getBytes(), HMAC_HASHING_ALGORITHM));
byte[] hash = mac.doFinal(message.getBytes());
```
ClickUp computes `x-signature` as HMAC-SHA256 over the **raw UTF-8 bytes**
of the request body. So any webhook whose payload contains a non-ASCII
character — a task name, a comment, an assignee's name — only validates on a
JVM whose default charset happens to round-trip those bytes:
- **US-ASCII** (what a container in the `C`/`POSIX` locale gets on a JVM
before 18): the decode replaces each non-ASCII byte with `U+FFFD` and the
re-encode writes `?`, so the computed HMAC cannot match and the delivery is
rejected with `InvalidMessageSignatureException`.
- **ISO-8859-1**: the round trip is byte-preserving, so it works by accident.
- **UTF-8**: correct.
The result is a webhook that verifies on a developer's laptop and rejects
every non-ASCII event in production, with a signature mismatch as the only clue.
## Fix
Name UTF-8 at all three places — the body decode and both `getBytes()`
calls. An all-ASCII payload hashes to exactly the same value as before, so
existing deployments are unaffected.
The `InvalidKeyException` branch also logged the key, which is the webhook's
shared secret:
```java
LOG.debug("This exception should never occur: the provided key is not valid.
{}", key);
```
That is dropped — the exception is still propagated, just without writing
the secret to the log.
## Tests
New `UtilsTest`:
- `shouldComputeTheHmacOfAnAsciiMessage` pins the existing behaviour for
ASCII input.
- `shouldComputeTheHmacOverUtf8Bytes` uses a key and a message that are not
representable in US-ASCII and encode differently in ISO-8859-1, and asserts the
HMAC-SHA256 of their UTF-8 bytes. It fails on `main` on any JVM whose default
charset is not UTF-8, and it fails there for every default charset other than
UTF-8 and ISO-8859-1.
--
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]
