Dependent 3rd party library diff_match_patch is unmaintained

[bschoening]

diff-match-patch Github repo states "This repository has been archived by the owner on Aug 4, 2024. It is now read-only." According to comments in #143, there hasn't been a main update in 4+ years.

[altr-benjamin]

Following this

[safris]

@altr-benjamin, thank you for bringing this to my attention. What are you suggesting?

[bschoening]

@safris @altr-benjamin per OWASP Top 10 Vulnerable and Outdated Components, unmaintained dependencies shows up in surveys as a top 10 concern.

When compiling with Maven Central as a repo, this causes a build error 'Could not find diff_match_patch:diff_match_patch:current'.

``

[safris]

@bschoening, if you would like this resolved, please submit a pull request.

[altr-benjamin]

@safris the TL;DR is that I am using libj.math in a PR to improve performance in @bschoening 's library. I will take a look into this and see if its something I or a member of my team can address. Thanks.

Project: https://github.com/mysto/java-fpe
PR: mysto/java-fpe#15

[bschoening]

@safris it seems simply removing libj/util/Diff.java is the best (only?) option as that class wraps diff_patch_match. Diff does not appear to be used in the codebase of libj. I could submit that PR if the maintainers are ok with that approach.

[safris]

@bschoening, I don't want to remove libj/util/Diff.java, because I use it. Instead of me removing it, you could simply not use it, and mark the compliance warning as "does not apply, because I don't use libj/util/Diff.java".

[altr-benjamin]

@safris As we are looking at incorporating libj.util into a downstream lib, I think our concern is that diff_match_patch is listed as a "first-class" dependency and thus will be included in the downstream dependency tree. The consequence is that, from a SBOM perspective, although we can and have verified that diff_match_patch is just a development tool and is not used in the library and we know there's no cause for concern, it is difficult to attest that fact to 3rd parties on an ongoing basis.

For context, do you use Diff.java as a tool when you're actively developing the library, and if so does it need to be in the source tree? Would any of these be workable solutions for you:

• Moving Diff.java out of libj.util source and removing diff_match_patch as a dependency?
• Evaluating another diff tool for development?
• Accepting changes that will swap out diff_match_patch in Diff.java with an equivalent diffing library that is maintained?

[safris]

Hi @altr-benjamin, thank you for the in-depth explanation of your issue, and suggestion of possible solutions.

I now understand your concern, and would like to find a course of action that would work for the both of us.

Here is my feedback to your suggested solutions:

• Move Diff.java from libj.util and into some other library:
  1. Diff is used by https://github.com/jaxsb/jaxsb/blob/master/compiler/src/main/java/org/jaxsb/compiler/lang/NamespaceBinding.java#L27.
  2. Diff is also used by a number of private repositories, which includes at least one that I do not have access to any longer.
  3. If I were to move Diff.java out of libj.util, then it would break these dependent repositories.
• Evaluate another diff tool for development:
  1. Diff is used by dependent repositories in production, so the evaluation of another diff tool for development is not applicable.
• Accepting changes that will swap out diff_match_patch in Diff.java with an equivalent diffing library that is maintained:
  1. Sure, I would be happy to swap out diff_match_patch in Diff.java with an equivalent diffing library that is maintained. If you know of supported equivalents of diff_match_patch, please let me know. If such an equivalent library would prove to be functionally equivalent, then I would swap it in the place of diff_match_patch.