[
https://issues.apache.org/jira/browse/TINKERPOP-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723205#comment-17723205
]
Cole Greer commented on TINKERPOP-2948:
---------------------------------------
Thanks for driving these changes [~acoady].
I'm trying to better understand what impact this would have on TinkerPop users.
If we are ultimately forced to choose between a minor breaking change or
leaving an open security vulnerability, I would prefer the breaking change as
long as we fully understand the impact and have a mitigation plan for users.
It looks like the default token limits are quite large. The defaults appear to
be a max nesting depth of 1000, max number length of 1000, and a max string
length of 5000000. Those appear to be reasonable defaults and I wouldn't expect
many users to exceed them. The 2 questions I have regarding the limits is what
happens if the limit is exceeded? I would hope it results in a clear and
informative error message for the user. Also can we provide configuration
options for users to change these limits if their use case requires it.
My last question is about the failing tests you referenced. Are you referencing
the failed Github Actions tests from
[https://github.com/apache/tinkerpop/pull/2061] or are there others as well? In
those tests the only failure I see which I believe is directly linked to the
jackson changes is
{panel}
Error:
org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SackTest$Traversals.g_withSackXBigInteger_TEN_powX1000X_assignX_V_localXoutXknowsX_barrierXnormSackXX_inXknowsX_barrier_sack(org.apache.tinkerpop.gremlin.process.traversal.step.sideEffect.SackTest$Traversals)
{panel}
which is failing during the TinkerGraph tests in the JDK8 and JDK11 runs. The
traversal in question is
{code:java}
g.withSack(BigInteger.TEN.pow(1000),
Operator.assign).V().local(out("knows").barrier(normSack)).in("knows").barrier().sack()
{code}
BigInteger.TEN.pow(1000) will exceed the default limit. We will need to either
change this test to use a smaller value or amend the test system such that the
default size limits can be overridden.
Other than this one test, the only failure I am seeing in the Github actions
appear to be caused by missing packages and classes in Netty. It appears that
the jackson version bump has inadvertently broken Netty and will need more
investigation there.
> PRISMA security vulnerabilty for jackson-databind 2.14.0
> --------------------------------------------------------
>
> Key: TINKERPOP-2948
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2948
> Project: TinkerPop
> Issue Type: Bug
> Components: server
> Affects Versions: 3.6.3, 3.5.6
> Reporter: Aaron Coady
> Priority: Major
>
>
> h1. PRISMA-2023-0067 logged against jackson-databind 2.14.0
> [https://github.com/FasterXML/jackson-core/pull/827]
>
> com.fasterxml.jackson.core_jackson-core package versions before 2.15.0 are
> vulnerable to Denial of Service (DoS). The package 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 and leads to
> Uncontrolled Resource Consumption ('Resource Exhaustion')
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
