DanielLeens commented on PR #11557: URL: https://github.com/apache/seatunnel/pull/11557#issuecomment-6624348751
Thanks @SEZ9. F1 is addressed on `c5787154a16`. It isn't in the 11-03 table because none of those 11 commits touched it: the fix landed earlier and is unchanged on this head. Here is the row in the same format: | Issue | Commit | Root cause and fix | Test | |---|---|---|---| | PR11557-F1 (High, Security) | `5a0f93b37ded5b3e0b150fb18b66c60b31b0136d` | `readInternal` used to decode `readerLocation` with an untyped `in.readObject()`, and an intermediate fix used `readObject(TaskLocation.class)`. Hazelcast's typed overload does not validate the wire type: it discards the wire factory/class id and reads the following bytes positionally into a new `TaskLocation`. `ManagedSourceRegisterOperation#readInternal` (`ManagedSourceRegisterOperation.java:115-131`) now decodes by the wire id through the closed `TaskDataSerializerHook` factory. It then rejects anything that is not a `TaskLocation`, including `null`, with an `IOException` that names the expected type and the decoded type. This path uses no JDK `ObjectInputStream`. | `ManagedSourceRegisterOperationSerializationTest#testMismatchedReaderLocationTypeIsRejected` (`:92`) puts a `Progress` (same factory id, different class id) in the reader-location slot and asserts the exact `IOException`. It fails against t he typed-overload version. `#testReaderLocationPayloadRoundTrips` (`:65`) asserts that a real payload re-encodes byte for byte. | Verification: - `5a0f93b37de` is an ancestor of `c5787154a16`. - `git log 5a0f93b37de..c5787154a16` has no commits that touch the operation or its test. - On fork Build head `b00c3e0cdad` the test ran 2/2 with 0 failures in the unit-test lane: https://github.com/DanielLeens/seatunnel/actions/runs/37762848399/job/113270515885. - No fork Build has run on `c5787154a16` yet, so I'm not claiming a result for this head. The pre-existing untyped reads in `AssignSplitOperation#readInternal`, and the typed-override behavior in the base `TaskOperation#readInternal`, are not introduced by this PR. They are tracked in #12747, as you asked earlier. I'll add this row to the status table in the PR description. -- 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]
