Nexory commented on PR #2832: URL: https://github.com/apache/shiro/pull/2832#issuecomment-4965280975
Good question, @rmannibucau. I'd frame these as solving different problems, complementary to the global property rather than a replacement. **Scope is the main one.** `-Djdk.serialFilter` is process-global: it governs every `ObjectInputStream` in the app that doesn't set its own filter (caches, session/cluster replication, RMI/JMX, third-party libraries, ...). To make it strict enough to meaningfully constrain the RememberMe path, you'd have to enumerate every class the *whole application* legitimately deserializes anywhere, which isn't practical and risks breaking unrelated subsystems. A per-stream filter on the RememberMe sink only ever sees principal data, so it can be tightened to a small class allow-list the application owner actually knows (`com.example.MyPrincipal;!*`) without affecting anything else. Per-stream filtering is exactly the JEP-290 mechanism for this sink-specific case. **On-by-default, and config not flags.** The property has to be set on every deployment's JVM launch (container entrypoint / systemd / app-server args); it's easy to omit and lives in ops/infra config, invisible to the application. A conservative default in Shiro gives RememberMe baseline protection with no operator action, and the stricter allow-list is one line of Shiro config that travels with the application (version-controlled, reviewable) rather than a launch flag. To be upfront about scope: the default this PR ships is resource-limits-only (`maxdepth`/`maxrefs`/...). It bounds oversized or deeply-nested payloads but does not by itself stop known RCE gadget chains; the opt-in class allow-list is what does that. The value here is making that scoped, tight filter trivial to enable, plus a safe default, which the global property can't do as cleanly. -- 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]
