RFE for 3.x: separate module for default typing

[MarkusKull]

From FasterXML/jackson-future-ideas#41 :

Every so often a new class gets added to the "default typing" blacklist. Whenever this happens, security scanners report all projects using databind as having a critical vulnerability and requiring "remediation" in a short timeframe. While it is unlikely that any of the projects are actually using default typing, the scanners can't figure this out.

Instead for 3.x: Default typing setting could be offered via extra artifact and Module, and NOT as default feature of databind. Some or all supporting functionality can still reside within databind, but no need to offer easy enabling. (I would prefer some core functionality moved to the new module so to assure that default typing is only possible with the easily detectable artifact. But that is probably not needed.)

[cowtowncoder]

Thank you. This makes sense for 3.0, just need to think of best way to expose it, configurability.

[hpwdetica]

This would be very useful for us as well.

[tstibbs]

I think this is definitely needed, the number of vulnerabilities that are being raised against jackson due to default typing is making jackson almost unusable (because of the overhead of investigating those vulnerabilities).

Having said that, I personally don't agree with the fact that all these CVEs are being raised against jackson in the first place. The fundamental issue is that somewhere on your classpath you probably have a class which can be used to do something malicious when it's deserialised, and if you deserialise untrusted user input then the class could be used maliciously. Raising a CVE against jackson saying "it should block class x by default" only addresses that issue for that one particular class. It does not address the underlying issue that people are using jackson (with default typing enabled) to deserialise untrusted user input, and forcing people to depend on an extra artifact (if they want to use default typing) doesn't address it either. (but I'm still +1ing this because it does improve the situation for those who aren't using default typing!)

[cowtowncoder]

@tstibbs Just to make sure: with 2.10, implementation of #2195, including deprecated old methods, adding Javadocs, and making safe replacement use new new, means that I will not accept 2.10 and later as vulnerable to this category of vulnerabilities. Accepting them for 2.9 and earlier was probably a mistake, but it seems best to use this as a cut-off point.

So please hold on: 2.10.0 is planned to be released by end of next week (25 Sep 2019).
I recommend testing 2.10.0.pr3 with existing systems, if at all possible, to ensure smooth transition.

And yes, I am aware of how futile maintaining of block-list approach is, at this point.

As things are, wrt 3.x, it is actually not possible to enable block-list based approach at all: user will have to implement custom PolymorphicTypeValidator that is (too) lenient, register that with activateDefaultTyping().
So I am not even 100% sure how urgent removal would be; there is no longer a simple "just add this line" way to open possibility. And conversely not leaving ability to enable safe inclusion may be problematic for usage where user properly specifies rules like "all subtypes of [my safe base class] are ok" may cause problems with upgrade 2.x->3.0.

But this latter part can and should be discussed once we get back to developing 3.0 -- currently all focus is on 2.10.