Hi Richard, Thanks a lot for the detailed reviews, and for building both branches and running the tests locally on JDK 25.
Yes, that timeline works. I expect to push updated branches within the next day. I'll take #9076 first since it should land first: NullPointerException comes out of the tolerated set in favour of a typed check where the task id is resolved, the drop logging gets rate-limited with a running total plus a WARN for consecutive failures, and the failure counter moves to the top level of Server.getState with a stable zero. Then #9075: the defaults.yaml entry goes and the recommended pattern moves into SECURITY.md as a copy-paste block with the entries you listed and an explicit not-exhaustive note, the pattern gets validated at submit time, and the factory-scope and doc-scoping fixes land as well. Thanks also for spelling out the merge order. Landing #9076 first so a filtered payload is dropped and counted instead of killing the worker is the right composition, and I'll rebase #9075 once it lands. Kind regards, L1nq On Sat, Sep 5, 2026 at 2:40 AM Richard Zowalla <[email protected]> wrote: > Hi L1nq, > > thanks a lot for these, and for going through the serialization path so > carefully. > > I've left comments on both (#9075 and #9076), nothing fundamental, mostly > around a few details worth tightening. > > One practical note: we're discussing a release soon, so it would be great > to get these in before it goes out, given they're security-relevant. > > If you can address the review comments in the next few days, I think we > have a good shot at including them. Does that timeline work for you? > > Thanks again for the careful work here. > > Gruß > Richard > > > > Am 04.09.2026 um 15:23 schrieb xxx xxx <[email protected]>: > > > > Hello everyone, > > > > I've been doing a security review of Storm's serialization path. It > > produced two robustness issues on GitHub that are now filed, and I just > > opened a pull request for each. Since PRs don't reach this list by > default, > > here is a short notification. > > > > PR #9075 (closes #9073) adds a serial filter for the java serialization > > fallback bridge. A new config key, > > topology.fall.back.on.java.serialization.filter, holds a JEP-290 pattern > > that SerializableSerializer installs on every fallback deserialization, > so > > the filter is topology-scoped and covers local mode too. > conf/defaults.yaml > > ships a default deny-list of well-known gadget namespaces plus a 10 MB > > maxbytes cap; sites that need the old behavior can override or clear the > > key per topology. rzo1 suggested providing a PR for the option (2) > > mechanism in the issue thread. This ships that mechanism with the > deny-list > > enabled by default rather than empty — that choice and its one-line > > flip-back are described in the issue thread, and I'm happy to switch it > to > > an empty default if reviewers prefer. > > > > PR #9076 (closes #9074) stops undecodable messages from killing the > > receiving worker. Today any non-IOException decode failure escapes > recv(), > > reaches Utils.handleUncaughtException, and the worker exits. The change > > wraps each message's deserialization so the known decode-time exception > > types drop that one message with an ERROR log and a > deserializationFailures > > counter, while anything outside the tolerated set keeps today's behavior. > > Verified against a live 3.0.1-SNAPSHOT cluster: the same 27-byte frame > that > > kills a worker on master leaves the worker up and the topology active on > > the branch. > > > > Both carry tests (8 and 9 cases) and neither changes behavior for streams > > that decode cleanly. Review and feedback welcome — I'll follow the GitHub > > threads. > > > > https://github.com/apache/storm/pull/9075 > > https://github.com/apache/storm/pull/9076 > > https://github.com/apache/storm/issues/9073 > > https://github.com/apache/storm/issues/9074 > > > > Kind regards, > > > > L1nq > >
