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
