deps(maven): bump jackson-bom from 2.14.2 to 2.15.0

[dependabot]

Bumps jackson-bom from 2.14.2 to 2.15.0.

Commits

• 2c28e23 [maven-release-plugin] prepare release jackson-bom-2.15.0
• 35c5c4f Prepare for 2.15.0 release
• 3fc3624 Back to snapshot deps
• 246b73c [maven-release-plugin] prepare for next development iteration
• c2b35ab [maven-release-plugin] prepare release jackson-bom-2.15.0-rc3
• 814d8f5 Prepare for 2.15.0-rc3 release
• 365ee6a Back to snapshot deps
• 2ff14f1 [maven-release-plugin] prepare for next development iteration
• 78c68bc [maven-release-plugin] prepare release jackson-bom-2.15.0-rc2
• 9f26bd4 Prepare for 2.15.0-rc2
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[npepinpe]

It seems there's a default maximum constraint to string lengths in the convert with this update, of up to 5,000,000, added here: FasterXML/jackson-core#863

It seems in fact that the whole StreamReadConstraints is new to Jackson. While this doesn't seem to cause too many issues, it may cause more in the future. This is described in more details here: https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15#processing-limits

For backwards compatibility, we could of course set maximum limits, but as this was introduced for security purposes (specifically sonatype-2022-6438, a CWE-400 type), we might want to keep them and simply adapt it.

[sonatype-2022-6438] CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')
Description

jackson-core - Denial of Service (DoS)

The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.

The failing test is trying to set up a 10M variable. If we would like to support this, then we would have to make sure everywhere we use Jackson for such things, we'd need to allow tokens up to the maxMessageSize more or less.

This is easy to do for client side incoming messages, but a bit harder on the broker side for things like when converting decision outputs from message pack to JSON - what's the max message size there? We can use the default broker one, I guess 🤷

In that case, we can't use a static converter anymore, but instead it must be injected/passed around with configuration from the broker =/

Of course, another simpler approach (but one prone to the CVE I guess) would be to set a fairly high limit. However, as we don't limit our own message size, a user could always put something higher (unless we put, say, Integer.MAX_VALUE 😄).

[npepinpe]

The other option is assume our max message size sufficiently truncates things, and we simply don't worry about setting limits here. That leaves a possible OOM due to converting accumulated state from RocksDB, I suppose, but we're likely to run out of memory just holding it anyway, so perhaps we can simply set high limits here.

[npepinpe]

I think the solution will be to simply set no limit. As we never stream JSON, but rather we always have the complete payload already in memory, so an attacker wishing to DoS us via this vector would already be able to do this way before it hits the JSON parser.

[npepinpe]

bors merge

[ghost]

Build succeeded:

• Test summary