jackson-databind

Jackson had this problem a few months back, where someone reported a critical CVE against the project and broke builds all around the planet https://github.com/FasterXML/jackson-databind/issues/3972 Basically the programmer (not the attacker) had to write code where an object contained itself HashMap<String,Object> map=new HashMap<>(); map.put("recursive",map); After this, Jackson would indeed stack overflow if you asked it to wrap the object to JSON. Then again, half the build-in Java functions (e.g. getting an object hashcode for the map object) also fail for a recursive structure. The issue remains open 3 months later, Mitre still thinks it's hella serious, and people have yet again learned to just ignore their CI warning about CVEs

jackson-databind maintainer responds to a similar occurrence few weeks ago: https://github.com/FasterXML/jackson-databind/issues/3972#is...

https://github.com/FasterXML/jackson-databind/issues/2410 Block one more gadget type (HikariCP, CVE-2019-14540) https://github.com/FasterXML/jackson-databind/issues/2478 Block two more gadget types (commons-dbcp, p6spy, CVE-2019-16942 / CVE-2019-16943) https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-... # Safe Default Typing (safe Polymorphic Deserialization) https://medium.com/@cowtowncoder/jackson-2-10-features-cd880...

The email has a list of CVEs. Some are related to quite old bugs, as described here: https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-... The most recent relates to blocking yet another gadget: https://github.com/FasterXML/jackson-databind/issues/2478 As another commenter mentions, this whole set of issues is only a problem if you call enableDefaultTyping during setup, and then deserialise data from untrusted sources. Doubtless, there are people doing this. But don't.

This is one of the fixes: https://github.com/FasterXML/jackson-databind/commit/9593e16... It seems like it's a blacklist of types to not automatically de-serialize? If so, that's.... not good.

>it is apparently on by default Curious as to what makes you think this - I was under the impression you needed to explicitly call `enableDefaultTyping` to get this unsafe behaviour. The wiki page explicitly tells you not to do this with untrusted input and the method is deprecated in the latest versions of the library. https://github.com/FasterXML/jackson-databind/issues/2195 https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymo...

It is not necessary. I chose to build a protobuf based serialization and communication since it is widely used in distributed system and more performant than JSON based serialization. Another reason was ease of use especially because Netty already supports message encoders and decoders for conversion between protobuf and bytebuf. You could also use https://github.com/FasterXML/jackson-databind but that would require a reasonable amount of custom code for the encoder and decoders

Language maturity is not a one-dimensional problem and it's also not equal to the age of the language. To name just two ways in which I consider Rust more mature than Java: * It has a lot of fundamentals that are based on more academic languages which have explored some specific PLT space for a long time and let it mature. The fruits of that are now in Rust (many aspects of its type system for example). * Rust's community has an almost absurd ability (contrasted with most other languages) to focus on specific core libraries and tooling. For example serde[1], the Rust serialization library, is well-understood, simple, mature and supported in basically every Rust library out there. The second point is extremely impressive when contrasted with the state of things in Java-land, where you often have many different solutions for the same proble