Using Google gson vs FasterXML Jackson
Contributors
References
Project Recommendations for Package Upgrades
AAI R3 Security/Vulnerability Threat Analysis
Faster XML Jackson usage in Portal Code and replacing it with Gson
- AAI-628Getting issue details... STATUS
- AAI-908Getting issue details... STATUS
- AAI-910Getting issue details... STATUS
- AAI-928Getting issue details... STATUS
- AAI-1218Getting issue details... STATUS
Seccom Recommendations
15th July 2019: "Out of Scope" as per Fixing Vulnerabilities in the ONAP Code Base
Jackson Replacement
Security subcommittee has recommended teams move away from jackson, and will be presenting alternatives and asking for an assessment from each project. Our team will need to do an analysis - this would not be trivial, especially given how many of our repos are impacted. As of now, this would be a very high LOE for the team, we need to understand what the recommendation from the SECCOM is before we can provide better details on what the LOE would be.
Three Areas of Concern
- Direct usage of Jackson by ONAP code
- Frameworks configured with Jackson like Spring Boot
- Usage of Jackson by third-party tools like Cassandra
Survey of Replacement Options
Articles with comparisons and benchmarks:
- https://blog.takipi.com/the-ultimate-json-library-json-simple-vs-gson-vs-jackson-vs-json/
- https://github.com/fabienrenaud/java-json-benchmark
Rationale for eliminating some options from the articles above (about 20 libraries in total):
- Related to or derived from Jackson code
- Requires change to compilers and compile-time processes
- Counter-productive to CII Badging criteria, see also https://github.com/coreinfrastructure/best-practices-badge
- Unmaintained in recent years
- Vulnerabilities not addressed
- "Bus factor" too low
- Number of contributors and reviewers too low
Short-list of libraries as reasonable options to be explored, including:
- https://github.com/alibaba/fastjson
- https://github.com/google/gson
- https://github.com/square/moshi
- https://github.com/owlike/genson
Quick CVE comparison:
- https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=fastjson+or+gson+or+moshi+or+genson
- https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=fasterxml+or+jackson
Code Analysis
Search on AAI source code shows:
- approx 611 hits in 227 files for "fasterxml", which includes pom.xml and Java imports
- approx 978 hits in 215 files for "gson", which includes pom.xml and Java imports and initialising Java object
- zero hits for "fastjson"
- zero hits for "moshi"
- zero hits for "genson"
Code Examples
- aai\aai-common\aai-auth\src\main\java\org\onap\aaiauth\auth\AuthCore.java
- aai\aai-common\aai-core\src\main\java\org\onap\aai\auth\AAIAuthCore.java
Side-by-side comparison
FasterXML Jackson version | Google gson version | Comments |
---|---|---|
mapper = new ObjectMapper(); | JsonParser parser = new JsonParser(); | |
JsonNode rootNode = mapper.readTree(new File(authFilename)); JsonNode rolesNode = rootNode.path(AuthConstants.ROLES_NODE_PATH); | JsonObject authObject = parser.parse(authFile).getAsJsonObject(); JsonArray roles = authObject.getAsJsonArray("roles"); | Jackson's JsonNode is a more abstract data structure, compared with Gson's more concrete data structures JsonObject and JsonArray. |
String function = functionNode.path(AuthConstants.FUNCTION_NAME_PATH).asText(); | String roleName = roleObject.get("name").getAsString(); | Code structure differs at this point (function name vs role name) but the general intent of the code is equivalent (get the element name as a string). |
public synchronized void loadUsers(String authFilename) throws Exception (no exception handling in this method) | } catch (JsonProcessingException e) { ErrorLogHelper.logError("AAI_4001", globalAuthFileName + ". Not valid JSON: " + e); | For some reason, this version still catches com.fasterxml.jackson.core.JsonProcessingException even though it uses Google gson for parsing. Not a good idea to defer exception handling to the caller since the caller has no idea why/how/when/where the parsing failed and might be left with an invalid data structure as well. |
boolean hasMethods = handleMethodNode(methodsNode, role, function); | usrs.forEach((key, value) -> { ... }); | Method call vs Java lambda call is not really relevant to the Jackson replacement, but consistency of style could be an overall goal if the code is being re-factored anyway. |
POC: Replacing default Spring Boot Jackson dependencies with Gson - Tian Lee
I have investigated the feasibility of replacing all Jackson Spring Boot dependencies with Gson, by converting the two AAF security microservices, aaf-fproxy and aaf-rproxy to use Gson only.
The basic method I followed is detailed here: https://www.callicoder.com/configuring-spring-boot-to-use-gson-instead-of-jackson/
What I did:
- Exclude all transitive Jackson dependencies being pulled in from the Spring Boot dependencies.
- Exclude spring-boot-starter-json from spring-boot-starter-web
- Remove any spring-boot-starter-actuator dependencies, as they can only work with Jackson.
- Add a dependency to Gson (2.8.5), if one does not exist already.
At this point, if the application is only using Jackson for automatically serializing and deserializing request and response objects in its REST APIs, the conversion should be complete. Your Spring Boot application should now be switched to using the Gson implementation, and function as before.
Notes:
- I did not need to add the "preferred-json-mapper" property to my application.properties as stated in the link above. Spring Boot 2.0.3 seems to be capable of detecting and using the Gson dependencies on its classpath automatically.
- Additional complications and code changes may arise if you are explicitly using any of the Jackson library classes in your code. These will need to be manually converted to use the equivalent Gson classes instead.
- Jackson dependencies may be pulled in transitively from other AAI modules (such as aai-common). Excluding these manually in your own pom may be risky, so ideally they need to be fixed at the source.
Example an example of the changes I made to the pom.xml can be found in this changelist for the AAF rProxy project: https://gerrit.onap.org/r/gitweb?p=aaf/cadi.git;a=commitdiff;h=0d9b3896ad594816b1eb7048949114e6a18c4bd4
(Note that this changelist contains other code changes but only the pom.xml changes are required for switching to Gson)
Discussion from Seccom meeting 10th Oct
Actions:
- Maybe approach Cassandra team about also replacing Jackson?
- Share this with PTLs and aim for implementation in Dublin release?
Cassandra Usage of Jackson
- Mailing list archives for Cassandra: http://cassandra.apache.org/community/#mailing
- Suggested upgrade of Jackson major version (1.4 to 2+): https://issues.apache.org/jira/browse/CASSANDRA-4102
- Key feature of JSON support: https://issues.apache.org/jira/browse/CASSANDRA-7970
- Comment asking for JSON abstraction: https://issues.apache.org/jira/browse/CASSANDRA-7970?focusedCommentId=14333620&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14333620
- "Maybe we could abstract slighty our use of jackson (put the helpers we need in Json.java maybe?), so that 1) we have only one place to change if we upgrade jackson and the API change (or we want to change of library) and 2) we save creating multiple ObjectMapper or JsonStringEncoder objects."
- Comment asking for JSON abstraction: https://issues.apache.org/jira/browse/CASSANDRA-7970?focusedCommentId=14333620&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14333620
- Suggested move from json-simple to Jackson: https://issues.apache.org/jira/browse/CASSANDRA-8785
- Upgrade of Jackson minor version due to vulnerabilities (1.9.x): https://issues.apache.org/jira/browse/CASSANDRA-8974
- Upgrade of Jackson major version due to vulnerabilities (1.9.x to 2.9.5): https://issues.apache.org/jira/browse/CASSANDRA-14427
- Similar analysis of the databind problems and gave themselves a similar waiver: https://issues.apache.org/jira/browse/CASSANDRA-14427?focusedCommentId=16479994&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16479994
- "Assuming that condition is met, ObjectMapper also needs to be able to be able to handle polymorphic types.This can be done in 2 ways:
- ObjectMapper.enableDefaultTyping(). We don't do this in the code base.
- Explicitly defining polymorphic types using annotations JsonSubType or JsonTypeInfo. We don't do this either."
- "Assuming that condition is met, ObjectMapper also needs to be able to be able to handle polymorphic types.This can be done in 2 ways:
- Similar analysis of the databind problems and gave themselves a similar waiver: https://issues.apache.org/jira/browse/CASSANDRA-14427?focusedCommentId=16479994&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16479994
- Request sent to 'user@cassandra.apache.org' mailing list:
- Response from Greg Matza, who is "Enterprise Account Executive" at ScyllaDB: https://www.scylladb.com/company/#team
From: Greg Matza [mailto:greg@scylladb.com]
Sent: Friday, 12 October 2018 09:56
To: Keong Lim <Keong.Lim@huawei.com>
Subject: ScyllaDBKeong,
I saw your post on the Cassandra mailing list.
ScyllaDB is an open source drop-in replacement for Apache Cassandra. You can easily substitute Scylla for Cassandra in JanusGraph - in fact IBM has publicly spoken about why they chose Scylla instead of Cassandra for their JanusGraph as a Service. https://www.scylladb.com/tech-talk/performance-evaluation-scylla-database-backend-janusgraph-scylla-summit-2017/
And, because ScyllaDB is written in C++, there are no Jackson dependencies. So you'll be able to satisfy your security concerns, and take advantage of the fact that Scylla is faster and easier to manage.
We believe that there are already users of ScyllaDB within Huawei. For example, in March of 2018, our CEO and CTO met with Huawei Cloud, who are interested in offering Scylla as a Service. That potential partnership is still under discussion.
If you are interested in learning more, I would recommend dowloading the software at https://www.scylladb.com/download/, and joining our ScyllaDB Users Slack, where there are many Scylla users and engineers who can answer questions. http://slack.scylladb.com. (There is even a Chinese-language channel - #general-cn - on the Slack, if you prefer that to the mostly-English #general channel)
Good luck, and I hope to see you on the Slack!!!
Greg
---
Greg Matza
650-400-9648
From: Greg Matza [mailto:greg@scylladb.com]
Sent: Friday, 12 October 2018 12:02
To: Keong Lim <Keong.Lim@huawei.com>
Subject: Re: ScyllaDBSounds great!
I know that time is very short, but we are holding the Scylla Summit in 4 weeks - 6th November and 7th November. We will be near San Francisco. http://www.scylladb.com/scylla-summit-2018/ We welcome you and your team to attend the Summit, in order to better understand the technology and integrate with the user community.
There is also a full day of training on 5th November that would likely be valuable.
If it is possible for you and your team to come, I will be happy to waive the $500 fee for Training and Summit. Let me know, and I can arrange for the free registration. If necessary, I can also get you a letter of invitation, which may help with obtaining a visa.
Greg
From: Greg Matza [mailto:greg@scylladb.com]
Sent: Wednesday, 24 October 2018 03:58
To: Keong Lim <Keong.Lim@huawei.com>
Subject: Re: ScyllaDBKeong,
Google Alert notified me of your posting on the ONAP site. From that notification, I saw your notes on our conversation and learned a bit more about your project.
We are excited by the prospect of inclusion in the ONAP AAI project. Our co-founders - Dor Laor and Avi Kivity are well experienced with Linux Foundation projects, as they are the creator and early manager of the KVM Hypervisor. So working with OSS Foundations is in our company's DNA. In addition, telecom are among the early adopters of Scylla - AT&T, Verizon, Huawei, Comcast, T-mobile are all either running Scylla in Production or are in POC.
As you continue to research the viability of Scylla for AAI, I'd like to make our technical and executive resources available to you. From a technical perspective, we are available to help with any POC or evaluation. (Installation, hardware recommendations, monitoring setup, or other practical questions). From an executive perspective, we'd be happy to discuss any potential questions with roadmap, licensing or other 'vision'-type questions.
Let me know if/when you are ready to engage with our technical or executive resources.
Greg
From: Greg Matza [mailto:greg@scylladb.com]
Sent: Tuesday, 11 December 2018 13:01
To: Keong Lim <Keong.Lim@huawei.com>
Cc: stephen.terrill@ericsson.com; jf2512@att.com; Maheedhar Gunturu <maheedhar@scylladb.com>
Subject: Re: ScyllaDBKeong,
Unfortunately, we don't have a public demo lab that you can point your application at. The closest we have is the Scylla Test Drive, which spins up a cluster on AWS and gives you SSH access to the nodes, but the cluster only runs for an hour, and you are mostly stuck with cassandra-stress. (https://www.scylladb.com/test-drive/) Better than nothing, but not perfect.
For your testing, we are happy to share all the necessary instructions on how to get started using Scylla with Kubernetes and give you access to our Helm Charts and stateful sets. We are also happy to make ourselves available over Slack and/or web conferences to help set everything up.
Hardware requirements are https://docs.scylladb.com/getting-started/system-requirements/. Scylla will probably run on your laptop, but the official testing and Production recommendations are:
Installation
Cores
Memory
Disk
Network
Test, minimal
4
2 GB
Single plain SSD
1 Gbps
Production
20 cores - 2 socket, 10 cores each
128 GB
RAID-0, 4 SSDs, 1-5TBs
10 Gbps
Ultimately, if you can share workload specs with us, we can make hardware sizing recommendations.
Slack invitations are available at http://slack.scylladb.com. Binaries are at https://www.scylladb.com/download/#binary (or https://www.scylladb.com/download/#docker). Let us know when you have the cycles to do some testing.
Greg
On Mon, Dec 10, 2018 at 4:35 PM Keong Lim <Keong.Lim@huawei.com> wrote:
Hi Greg,
To that end, do you have some public demo lab available that runs Scylla in a Kubernetes cluster, where we could push some data and queries through to observe the behavior and collect stats?
What would be the min/max/default CPU/RAM resources to configure in the pods?
ONAP project has its own Cassandra clusters running in various test labs, so a virtual-side-by-side comparison might provide an interesting data point to consider.
Keong
From: Greg Matza [mailto:greg@scylladb.com]
Sent: Tuesday, 11 December 2018 11:02
To: Keong Lim <Keong.Lim@huawei.com>
Cc: stephen.terrill@ericsson.com; jf2512@att.com
Subject: Re: ScyllaDBSounds good.
Of course, Jackson vulnerabilities may be the bleeding wound that needs to be patched up most urgently. But there are also other benefits of Scylla vs. Cassandra. Namely, easier maintenance (no JVM tuning, no cache tuning, etc.), and typically cheaper/better performance on fewer nodes.
I just mention this because the idea of Scylla as a wholesale replacement for all the C* throughout AAI (and even ONAP) came up on your last discussion. (I listened to the recording) Obviously, we'd encourage that! We think our software is awesome! But, beyond our boosterism, there might be real value to users, beyond the Security aspects.
Look forward to hearing from you,
Greg
On Mon, Dec 10, 2018 at 3:56 PM Keong Lim <Keong.Lim@huawei.com> wrote:
Hi Greg,
The issue of replacing Jackson libraries came up again from a security standpoint, so there may be some appetite to look at a Cassandra replacement as part of that work.
The discussion right now is about which use cases will be included in the next release, but priorities have not been agreed yet.
Will keep Scylla in mind when the topic does come up again!
Keong
From: Greg Matza [mailto:greg@scylladb.com]
Sent: Tuesday, 11 December 2018 10:28
To: Keong Lim <Keong.Lim@huawei.com>
Subject: Re: ScyllaDBKeong,
Congrats on the Casablanca release.
We're here to assist with any testing or discussion, once the Cassandra/Scylla question comes up again, as part of Dublin. Any thoughts on when that might be?
Greg
ScyllaDB as replacement for Cassandra
- Intended as a drop-in replacement for Cassandra (works with existing Cassandra driver in JanusGraph)
- Written in C++ rather than Java
- Benchmarks faster than Cassandra: https://www.scylladb.com/product/benchmarks/
- Available under AGPL: https://github.com/scylladb/scylla
- AWS test cluster: https://www.scylladb.com/test-drive/
- Hardware requirement: https://docs.scylladb.com/getting-started/system-requirements/
- Possibility of doing virtual-side-by-side comparison test?
Quick CVE comparison:
- https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=scylla+or+scylladb
- https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=cassandra
Discussion from PTL meeting 15th Oct
Actions:
- Should ONAP pay for Jackson project to fix the vulnerabilities?
- Could ScyllaDB be used to replace Cassandra?
- 2019-09-17: point Greg Matza towards Mike Elliott of OOM team as maintainer of shared/common Cassandra (and other databases).
VF2F December 2018
- Mentioned again for Dublin release S3P requirements at ONAP Project Developers Event, Dec 10 - 12, 2018, (Virtual Webinars)
Conclusion So Far
For AAI project:
- code already uses Google gson, so
- gson has already been scanned for vulnerabilities
- gson does not appear on Seccom lists for package upgrade or replacement
- currently no usage for the alternative Json libraries, so
- introducing the new libraries may also bring in new vulnerabilities and problems
- there is already at least one worked example for translating from Jackson usage to gson usage, facilitating further conversions to gson
- the POC shows that transitive dependencies on Jackson could also be eliminated in some cases
- there are nearly 30 AAI repositories and over 200 files that need to be updated
- fully eliminating Jackson may not be possible due to other tools, such as Cassandra
- could Cassandra be replaced by using ScyllaDB?