We are using a library from the old day of fabric8. We need to switch to something else if we want to upgrade.

Yes, I discussed this with @rohanKanojia the other day. That library is based in a fork of another repo. We might just depend on the original library.

Also the CVE is related to Jackson. I don't think there's a transitive dependency and the Client's Jackson dependency should be the applicable one. But we definitely need to tackle this.

The latest version of https://github.com/flipkart-incubator/zjsonpatch is using jackson 2.10.3, which is not affected by the CVE

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

@mattnelson @manusa the cve listed above applies just to the project, not to its usage in the fabric8 client - which uses its own managed version of the jackson dependencies. An issue with directly depending on the original project is that it brings in a transitive dependency on commons collections. Part of the motivation for the fork seems to have been removing that (and at the time the guava) dependency - https://github.com/fabric8io/zjsonpatch/tree/master/src/main/java/io/fabric8/zjsonpatch/internal

Are we open to adding a dependency (optional or otherwise) on commons collections?

If not we should try to push the upstream project to accept changes that will isolate or remove that dependency.

Another issue with directly depending on the original project is that it brings in a transitive dependency on commons collections. Part of the motivation for the fork seems to have been removing that (and at the time the guava) dependency -

guava/commons-collections4 are removed in 0.4.0 via flipkart-incubator/zjsonpatch#60

guava/commons-collections4 are removed in 0.4.0 via flipkart-incubator/zjsonpatch#60

looks like common-collections4 worked its way back in https://github.com/flipkart-incubator/zjsonpatch/blame/master/pom.xml#L149