Egeria security updates

[Shrinivas-Kane]

we need to upgrade following libs due to security vulnerabilities

• org.codehaus.jackson:jackson-mapper-asl:1.9.13 -> moved as jackson-databind
• jackson-databind upgrade to 2.11 or higher
• org.apache.tomcat.embed:tomcat-embed-core to 9.0.40 due to CVE-2020-9484 , CVE-2020-13935
• gremlin-shaded to 3.4.8 due to CVE-2020-24750, CVE-2020-24616, CVE-2020-14195, CVE-2020-14062, CVE-2020-14061, CVE-2020-14060,
• io.netty:netty-all to 4.1.44.Final due to CVE-2019-20444
• com.thinkaurelius.thrift:thrift-server to 0.3.9 due to CVE-2019-0205 ( looks like very outdated lib)
• org.apache.thrift:libthrift to 0.13.0 due to CVE-2019-0205 ( looks like very outdated lib)
• org.yaml_snakeyaml due to CVE-2017-18640

@cmgrote / @mandy-chessell can we please prioritize this issue ?

[grahamwallis]

@Shrinivas-Kane Thanks Shrinivas. It looks like moving Cassandra up to 3.11.9 would resolve the thrift related dependencies.

@lcpopa Is there are a reason that we are using Cassandra 2.2.13? It looks quite old now (2018). Would it be possible to move up to at least 3.11.9?

[grahamwallis]

Actually I think my assertion above about 3.11.9 is incorrect:
Our current Janusgraph (latest, 0.5.2) is tested with Cassandra 3.11.0, but that still uses
thrift-server 0.3.7
libthrift 0.9.2
Even Cassandra 3.11.9 appears to still use the same versions.
So we would need to 'manually' pull in later versions of the dependencies, but we should assess whether that would be feasible. @planetf1 @lcpopa Thoughts?

[grahamwallis]

This is also mentioned in #2671

[planetf1]

We generally update the prereqs once a month.

• jackson-mapper is not used directly, though we do specify a transitive dependency version in the top level pom.xml. This is still pulled in by janus's cassandra support & hadoop-common. We do then define dependencies on these so the jar does get pulled into egeria. The egeria code itself is already using the current modules. We have a plan to move the hadoop support to a new repo (and look at updating versions there). See Move ranger code to new repo #458 . Graham has commented on janus - and more generally we need to dynamically load connectors to reduce what dependencies are brought in for everyone. We also have a cassandra metadata extrator connector -- Some discussion of moving this code in Cassandra metadata extractor connector move to a separate repository? #4095
• Jackson-databind is already at 2.11.3
• tomcat-embed-core is 1 step back -- we usually update all our dependencies in each build cycle. We did back-off our spring related changes this month (which may have included tomcat) due to a compatability issue with our azuul usage in the UI . I don't have any undue concerns about making this change , however in checking the CVEs the ones mentioned are already covered in .39, so I would propose leaving as is until the next monthly cycle.
• gremin-shaded is already at 3.4.8
• netty-all is already much later at 4.1.53
• see graham's comments on thrift
• snakeyaml is already much later at 1.27

So I think the main question here is what we do about cassandra & janus graph. IMO Egeria should not have a dependency on cassandra, or even Janus's cassandra support. That is a deployment decision only, and should be made by the user/installer of egeria. We need to document enough to allow the user to do this, but should absolutely not include anything beyond the interface api as a dependency. @grahamwallis ?

[lenawoolf]

@planetf1 Nigel, I agree that Egeria should not depend on Cassanda and Janus

[planetf1]

#2671 is already open to address the janusgraph/cassandra cleanup so I believe we can close this as the other issues are addressed