I agree that the GIL situation is unfortunate. Python at least does not pretend their it-just-works serialization is secure. The documentation [1] actively dis

I agree that the GIL situation is unfortunate. Python at least does not pretend their it-just-works serialization is secure. The documentation [1] actively discourages deserializing untrusted data and suggests to use pure data format (e.g. JSON) as possible. In contrast, the documentation on ObjectInputStream before Java 11 does not warn about this at all. Even then [2], it suggests to implement blacklist/whitelist filters, and it is pretty hard to get right. The same filtering can also be done for pickle, but the usual consensus in Python developers seems to be "don't do this even if it's possible". > but from what I have seen ClassLoader/Import abuse is alive in both languages. Yeah, should have said that my rant is mainly against endless deserialization/OGNL injection/whatever-popular-expression-language injection bugs in frameworks, not abusing ClassLoader. These features, just like log4j2's code-execution-disguised-as-string-interpolation feature [3], shouldn't exist. [1] https://docs.python.org/3/library/pickle.html https://docs.python.org/3/library/pickle.html [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/ObjectInputStream.html https://docs.oracle.com/en/java/javase/11/docs/api/java.base... [3] I'd argue that's the real bug, instead of the obvious JNDI class loader blah blah stuff. Luckily log4j didn't refuse to fix it and completely removed "message lookup".