Upgrade commons-text to 1.10.0 due to CVE-2022-42889

[Ironlink]

See https://nvd.nist.gov/vuln/detail/CVE-2022-42889

I tried to build the project locally to see if there were any compatibility issues. I can build and test Handlebars.java, and I can compile but not test the next module Handlebars. Tests fail because I don't have a JDK old enough to support Nashorn (removed in JDK 15).

[svettwer]

Seems like it's a more complicated fix without a new handlebars release, because the vulnerability is shaded into a internal package here https://github.com/jknack/handlebars.java/blob/master/handlebars/pom.xml#L46-L49

[gderemetz]

Hello, this issue will be fixed quickly ? thx

[aschwarte10]

We are a happy user of the Handlebars library. The current version of handlebars appears in different vulnerability scanners due to the above mentioned CVE.

We have provided a PR in #1010 that updates the commons-text dependency to the latest non-affected version.

Would be great to see a new version of handlebars.java being published soon

[jknack]

I will review, merge and release in the following days.

Thanks.

[svettwer]

It seems like PR #1010 upgrades the dependency but does not remove the shaded copy which is dead code as far as I can see. So CVE scanners might react on that as well, depending on their implementation.
I'll propose another PR removing this as well.

[jknack]

@svettwer I will do it.

[svettwer]

Ah, just raised the PR! 😄
Feel free to close it if you already did it.

[jetztgradnet]

So CVE scanners might react on that as well, depending on their implementation.

They do, that's why @aschwarte10 created the PR to update the dependency...

That's the problem with shaded dependencies. I understand why they exist, but they are hidden and make dependency management and copying with vulnerabilities really difficult

[jknack]

@svettwer don't we just need to update the dependency?

Shade plugin will use the new library.

[svettwer]

Yeah but in case a CVE in this lib happens again, we are unable to exclude/update the dependency by gradle for example. If the shading is not 100% necessary, it should be avoided to be able to make use of the third party dependency exclusion/update features of gradle and/or maven.

[jetztgradnet]

Shade plugin will use the new library.

It will, so the merged PR satisfies the (minimal) requirement for the update already.

But when it is shaded, it's baked in. If it was only a regular dependency like Jackson or others, everybody could simply just update their own dependencies in the respective application without any code changes in the handlebars library and it would not be as urgent and requiring your time and attention...

[jetztgradnet]

Same actually for Commons Lang3 and Antlr.

Antlr is shaded quite often because of how it works with different Java versions or different library version used by different frameworks, but even then ideally there would be no need for shading anything.

But simply removing shading might make the library backwards incompatible, as now these dependencies are required and need to be provided by an application, so this might actually rather be something for a 4.4 or 5.0 release.
(Although I certainly wouldn't mind having this removed now already, because we explicitly manage all dependencies anyway and don't rely on transitive dependencies ;-) )

[jknack]

are all you OK to remove shaded dependencies? If so, I can plan to remove them in 5.x (and requires Java 11 at minumum)