oscerd opened a new pull request, #28949:
URL: https://github.com/apache/camel/pull/28949

   Fixes [CAMEL-26258](https://issues.apache.org/jira/browse/CAMEL-26258), 
found while adding the catalog body types (CAMEL-24961).
   
   ## 1. A binary stream or File plaintext is corrupted
   
   **Was:** `KMSUtils.encodePlaintextForEncrypt` Base64-encoded a `byte[]` as 
it is and a `String` in UTF-8, but converted any other body with 
`getBody(String.class)` and then to UTF-8 before Base64. A binary `InputStream` 
or `File` was changed before it was encrypted, without an error (00 ff fe 41 80 
7f became 00 ef bf bd ef bf bd 41 ef bf bd 7f), so `decrypt` gave back 
different bytes. A binary `GenericFile` from a file consumer failed with a 
`TypeConversionException` caused by a `MalformedInputException`. A `Map` or a 
POJO was encrypted as its `toString()`.
   
   **Now:** a body that is not a `byte[]` or a `String` is converted with 
`getMandatoryBody(byte[].class)` before Base64, so an `InputStream`, a `File` 
and a `GenericFile` are encrypted unchanged: the Base64 plaintext sent to KMS 
decodes to the original bytes. The `plaintext` option or header still wins over 
the body, a `String` is still encrypted in UTF-8 and a `byte[]` as it is. No 
body still fails with `IllegalArgumentException: Plaintext is required for 
encrypt`, and the client is not called. A body that does not convert to bytes, 
such as a `Map` or a POJO, now fails with an `InvalidPayloadException` that 
names its type. The catalog body types (`producerIn`) are updated to match.
   
   The issue proposes `getBody(byte[].class)`. `getMandatoryBody` is used 
instead: with `getBody`, a body that does not convert gives null and would fail 
with "Plaintext is required for encrypt", as if there were no body.
   
   ## Tests
   
   - New `EncryptPlaintextTest` (8 tests) with a Mockito `Client` set on the 
endpoint, which captures the `EncryptRequest` and decodes its Base64 plaintext. 
It covers a `String` with non-ASCII text, a `byte[]`, an `InputStream`, a 
`File` and a `GenericFile` holding the bytes 00 ff fe 41 80 7f, no body, a 
`Map` and a POJO.
   - With the `src/main` changes reverted, 5 of the 8 tests fail: the stream 
and the file on the corrupted bytes, the `GenericFile` on the old 
`TypeConversionException` (`MalformedInputException`), and the `Map` and the 
POJO because no exception is thrown (they were encrypted as their 
`toString()`). The 3 that pass are the `String`, the `byte[]` and no body, 
which do not change.
   - Module tests: 9 tests, 0 failures.
   
   ## Docs and generated files
   
   - Component doc: a new "Plaintext of encrypt" section: which plaintext is 
encrypted, how each body is read, and that the `plaintext` of `decrypt` is 
Base64 for these bytes.
   - The `@BodyTypes` description of `KMSEndpoint`; the regenerated 
`alibaba-kms.json` and the doc are copied into the catalog.
   - Upgrade guide entry for 4.24: a stream or a file is encrypted as its 
bytes, and a body that does not convert to bytes fails with an 
`InvalidPayloadException` instead of being encrypted as its `toString()`.
   
   ## Not changed
   
   - `decrypt` still reads the ciphertext blob as text, and `generateDataKey` 
does not use the body.
   - A `Map` or a POJO is not marshalled to JSON by the component, as that 
would be a new feature. It fails, so the route marshals it first.
   
   Main only, as the other fixes of the CAMEL-24961 follow-ups.
   
   _Claude Code on behalf of Andrea Cosentino (oscerd)_
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
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]

Reply via email to