Skip to content
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

Closed
Ironlink opened this issue Oct 17, 2022 · 21 comments
Closed

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

Ironlink opened this issue Oct 17, 2022 · 21 comments
Labels
Milestone

Comments

@Ironlink
Copy link

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
Copy link

svettwer commented Oct 17, 2022

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
Copy link

Hello, this issue will be fixed quickly ? thx

aschwarte10 added a commit to metaphacts/handlebars.java that referenced this issue Oct 18, 2022
Fix CVE-2022-42889

Note that Apache Commons Text is packaged as a shaded dependency.
@aschwarte10
Copy link
Contributor

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
Copy link
Owner

jknack commented Oct 18, 2022

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

Thanks.

jknack pushed a commit that referenced this issue Oct 18, 2022
Fix CVE-2022-42889

Note that Apache Commons Text is packaged as a shaded dependency.
@svettwer
Copy link

svettwer commented Oct 18, 2022

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
Copy link
Owner

jknack commented Oct 18, 2022

@svettwer I will do it.

@svettwer
Copy link

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

@jetztgradnet
Copy link

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
Copy link
Owner

jknack commented Oct 18, 2022

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

Shade plugin will use the new library.

@svettwer
Copy link

svettwer commented Oct 18, 2022

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
Copy link

jetztgradnet commented Oct 18, 2022

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
Copy link

jetztgradnet commented Oct 18, 2022

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
Copy link
Owner

jknack commented Oct 18, 2022

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)

@jetztgradnet
Copy link

yes, getting rid of shaded libraries would be great!

Thanks for looking into this, @jknack!

@svettwer
Copy link

svettwer commented Oct 18, 2022

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.

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.

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)

Yeah, would work for me as well!
Thanks @jknack for your quick reaction on this! 🤗 ❤️

@jetztgradnet
Copy link

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.

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)

@svettwer
Copy link

Oh, good catch! Sure, did not think about that. 👍

@jknack jknack added the bug label Oct 18, 2022
@jknack jknack added this to the 4.3.1 milestone Oct 18, 2022
@jknack
Copy link
Owner

jknack commented Oct 18, 2022

Pushed 4.3.1 to central will be available shortly.

@jknack jknack closed this as completed Oct 18, 2022
@jetztgradnet
Copy link

Excellent work, thanks a million, @jknack!

@aschwarte10
Copy link
Contributor

Also from my side, thanks 👍 @jknack

@svettwer
Copy link

Awesome work @jknack! Thanks so much! 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants