SEZ9 commented on PR #11557: URL: https://github.com/apache/seatunnel/pull/11557#issuecomment-5863679298
Thanks for the follow-up commit. The delta between `2dc5c3de085f` and `96e52dff9c4` is the one-line change in `ManagedSourceRegisterOperation.java` (`in.readObject()` → `in.readObject(TaskLocation.class)`) addressing PR11557-F1 (unsafe deserialization). **What it closes.** With the typed overload, Hazelcast's `DataSerializableSerializer` no longer goes through `dsf.create(id)` for the wire-supplied `factoryId`/`classId`; it instantiates `TaskLocation` directly and calls `readData(in)` on it. The risk of a hostile or corrupted payload selecting some other registered class is structurally gone. **What it does not do.** The `Class` argument is an override, not a validator. The wire `factoryId`/`classId` are still read but discarded rather than compared against `TaskLocation`'s own ids. A payload written for a different `IdentifiedDataSerializable` is still consumed positionally by `TaskLocation#readData`, which either fails on garbage bytes in a nested `readObject()`/`readString()` or, in the worst case, yields a silently mis-populated `TaskLocation`. So F1 is downgraded, not fully resolved. **Remaining asks for F1:** 1. Add an explicit check that the wire `factoryId`/`classId` match `TaskLocation`'s declared ids and fail fast with a clear exception on mismatch. If you'd rather leave this as a documented residual, please say so in the PR and add a short code comment explaining why the typed override is considered sufficient. 2. Add a unit test that feeds the read path a payload with a mismatched `factoryId`/`classId` and asserts it is rejected rather than deserialized into a `TaskLocation`. 3. Let us know whether any other `readObject()` calls in the managed lane operations follow the same pattern, so they can be fixed here or tracked explicitly. Once those are in, I'm comfortable marking F1 closed. Everything else from the prior review stands as-is. <!-- streview-comment:1381 --> -- 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]
