DanielLeens commented on PR #11559: URL: https://github.com/apache/seatunnel/pull/11559#issuecomment-6624349648
Thanks @SEZ9. None of `bb23b9f2`, `a4ab739b` or `949ac4f7` touches `KafkaSourceReader.java`, because the fix landed earlier and nothing has changed it since. **1. The commit.** The hardening is `5458405ede00c693da216f02c07908e4b11b11e7` (described in https://github.com/apache/seatunnel/pull/11559#issuecomment-6394093084). It is an ancestor of the current head `949ac4f7076`. `git diff 5458405ede0 949ac4f7076 -- seatunnel-connectors-v2/connector-kafka` touches only `KafkaPartitionSplitReader` and its test, both from the dev merge and both off the gate path. On the current head: - `KafkaSourceReader.java:237-247`: `restoreGateState` checks each staged split's SHA-256 and then calls `deserializeSplit`. - `KafkaSourceReader.java:404-407`: `deserializeSplit` constructs only `KafkaGateObjectInputStream`. That class (`:425`) is the only `ObjectInputStream` in connector-kafka production sources. - `KafkaSourceReader.java:432-450`: `resolveClass` matches exact names only: `[B`, `String`, `Long`, `Integer`, `KafkaSourceSplit`, `TopicPartition`, `TablePath`. There is no prefix or package match, and every other array is rejected. - `KafkaSourceReader.java:460-462`: `resolveProxyClass` throws before any interface or handler is resolved. On the direction you prefer: this path never deserializes record payloads. Kafka records still go through the configured format deserializer, as before. The Java decoding is limited to the reader's own split objects, which `snapshotGate` stores in the engine checkpoint while the gate is closed. That case is the "genuinely required" one, and it is restricted to the exact types the reader writes. **2. Unit tests.** These already exist in `KafkaSourceReaderGateTest` and drive the production `deserializeSplit`: - `productionDeserializeSplitShouldRejectClassOutsideAllowlist` (`:146`, `HashMap`) - `...RejectSamePackageSubclassOutsideAllowlist` (`:170`, `KafkaSourceSplitState`, which defeats prefix and `instanceof` checks) - `...RejectArraysOutsideAllowlist` (`:185`) - `...RejectProxyClassesBeforeTheirHandler` (`:204`) - the positive `...RoundTripKafkaSourceSplit` (`:135`) Each rejection test asserts the exact rejection message. **3. PR description.** You're right that the description explains the decoder's mechanics but not why it is safe. I'll add a short "Kafka gate state: why Java deserialization is safe here" paragraph covering the input source (engine checkpoint only, never record payloads), the trust boundary (the SHA-256 detects corruption but is not authentication, so the exact-name allow-list is the real control even when the checkpoint store is untrusted), and the tests above. This is a description update only. No code change is pending for this finding. -- 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]
