oscerd opened a new pull request, #24716:
URL: https://github.com/apache/camel/pull/24716
# CAMEL-23843: Camel-PQC — sign and verify String payloads as UTF-8
## The bug
`PQCProducer` sign/verify (and the hybrid variants) read the body and, when
it is not already binary,
encode it with `String.getBytes()` — i.e. the **JVM default charset**. The
default charset is platform
dependent, so signing on one JVM and verifying on another with a different
default disagrees on the
bytes of a **non-ASCII** payload and verification fails.
The issue also called out that binary payloads were forced through a String
conversion. **That half is
already fixed on `main`** by CAMEL-23847 (#24644, merged): `byte[]` and
`InputStream` bodies are now fed
to the signature byte-for-byte. What remained is the charset.
## The fix
Pin `StandardCharsets.UTF_8` in both body-to-bytes fallbacks
(`updateSignatureFromBody`, used by
sign/verify, and `bodyToByteArray`, used by the hybrid variants), so sign
and verify always agree on
the encoding. Binary bodies are untouched.
## Scope / honesty about impact
On **Java 18+** the default charset is already UTF-8 (JEP 400), so this is a
**no-op** there — the value
of the change is that the encoding becomes *explicit and deterministic*
rather than
environment-dependent. On **Java 17** with a non-UTF-8 default (which Camel
still supports) the bug is
live, and this fixes it.
Because it can change the signature of a non-ASCII `String` payload on such
a JVM, it is documented in
the **4.22 upgrade guide**.
## Testing
New `PQCSignatureCharsetTest` (2 tests):
- a `String` body and its UTF-8 bytes are **interchangeable** — signing the
String verifies against the
UTF-8 bytes and vice versa;
- a **negative** check: a signature over the String must *not* verify
against the same text encoded as
ISO-8859-1.
The existing `PQCStreamingSignatureTest` (5) still passes. Module build
green, no generated drift.
## Backport
**4.18.x (4.18.4)** and **4.14.x (4.14.9)**. Those branches do **not** have
CAMEL-23847, so the
binary-payload half of this bug is still live there — the backports
therefore also bring the
`byte[]`/`InputStream` body handling, without which the bug is only half
fixed on those branches. This
is called out in each backport PR.
---
_Claude Code on behalf of Andrea Cosentino._
--
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]
