L1nq0 commented on code in PR #9075: URL: https://github.com/apache/storm/pull/9075#discussion_r3946582318
########## conf/defaults.yaml: ########## @@ -309,6 +309,7 @@ topology.upstream.feedback.freq.secs: 10 topology.upstream.feedback.enable: false topology.builtin.metrics.bucket.size.secs: 60 topology.fall.back.on.java.serialization: false +topology.fall.back.on.java.serialization.filter: "!org.apache.commons.collections.functors.*;!org.apache.commons.collections.comparators.*;!org.apache.commons.collections4.functors.*;!org.apache.commons.collections4.comparators.*;!org.apache.commons.beanutils.*;!org.apache.xalan.xsltc.trax.*;!com.sun.org.apache.xalan.internal.**;!com.sun.rowset.*;!com.sun.org.apache.rowset.internal.*;!com.mchange.v2.c3p0.**;!org.codehaus.groovy.runtime.ConvertedClosure;!org.codehaus.groovy.runtime.MethodClosure;maxbytes=10485760" Review Comment: Both halves, in the revision pushed as 54e4926. The pattern (now a sample under docs/SECURITY.md rather than a shipped default, as agreed on rzo1's review) gained maxarray=1048576 alongside maxdepth=64;maxrefs=2097152;maxbytes=10485760. The docs no longer present maxbytes as the bridge's size cap. It is now described as per object (a new ObjectInputStream per value) and best-effort, for the reason you found: the array check runs before the bytes are read, so one big array can overshoot it. That is what maxarray is for. For the readInt pre-allocation: read() now validates the declared length before allocating. Negative lengths are rejected on any input. On buffered input (which is what the tuple path uses) a declared length that exceeds the bytes remaining in the input is rejected with a KryoException before the buffer is allocated. Stream-backed programmatic use is exempt from the upper bound, since the stream may still deliver the declared bytes (examples/storm-loadgen feeds Input over a request InputStream, and an available()-style check would misfire on legal frames there). The docs state the scope of the guard and a test covers it. -- 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]
