New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade commons-text to 1.10.0 due to CVE-2022-42889 #1009
Comments
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 |
Hello, this issue will be fixed quickly ? thx |
Fix CVE-2022-42889 Note that Apache Commons Text is packaged as a shaded dependency.
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 |
I will review, merge and release in the following days. Thanks. |
Fix CVE-2022-42889 Note that Apache Commons Text is packaged as a shaded dependency.
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. |
@svettwer I will do it. |
Ah, just raised the PR! 😄 |
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 |
@svettwer don't we just need to update the dependency? Shade plugin will use the new library. |
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. |
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... |
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. |
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) |
yes, getting rid of shaded libraries would be great! Thanks for looking into this, @jknack! |
This might be the case for Lang3 and Antlr. There I did no investigation. For commons-text, it should work, because we only updated from 1.9 to 1.10.0 anyways. There was no big jump in versioning.
Yeah, would work for me as well! |
the problem is not the version bump, but that right now (with 4.3.0) you can just use handlebars as-is without providing commons-text. When removing the shaded library, you would need to add this to your list of dependencies as it is no longer provided by the library internally... so an application using handlebars might break after updating to say 4.3.1 (at least when disabling transitive dependencies in Gradle as we do) |
Oh, good catch! Sure, did not think about that. 👍 |
Pushed 4.3.1 to central will be available shortly. |
Excellent work, thanks a million, @jknack! |
Also from my side, thanks 👍 @jknack |
Awesome work @jknack! Thanks so much! 🙏 |
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 moduleHandlebars
. Tests fail because I don't have a JDK old enough to support Nashorn (removed in JDK 15).The text was updated successfully, but these errors were encountered: