HBASE-30263 Exclude transitive netty-resolver-dns to mitigate CVEs#8453
HBASE-30263 Exclude transitive netty-resolver-dns to mitigate CVEs#8453xavifeds8 wants to merge 1 commit into
Conversation
| <dependency> | ||
| <groupId>io.netty</groupId> | ||
| <artifactId>netty-all</artifactId> | ||
| <version>${netty4.version}</version> |
There was a problem hiding this comment.
Can I ask why do we need to add netty-all to <dependencyManagement>?
As I see we only import netty-bom (line 1874) in <dependencyManagement> - we do NOT declare netty-all as a direct dependency. The comment at line 877-884 explicitly explains that netty-all historically caused classpath conflicts when mixed with individual netty modules, and the project solved this by pinning versions via the BOM.
Also HBase itself uses shaded netty via hbase-thirdparty repo.
There was a problem hiding this comment.
Good catch, you're right.
So currently 4.1.131.Final which has the CVEs in the DNS resolver modules. The proper fix would actually be to upgrade hbase-thirdparty 4.1.15 which is not yet released yet. which includes Netty 4.1.135.Final which has these CVEs resolved for netty-resolver-dns. So ideally once hbase-thirdparty 4.1.15 is out, we just consume that and this whole workaround becomes unnecessary.
given the classpath conflicts that comes up when mixing direct Netty dependencies with the shaded path i think it make sense to close this pr. We could bump up netty when thirdparty gets released.
There was a problem hiding this comment.
Just a few questions:
- Aren't netty-resolver-dns is brought in by the hadoop dependencies?
- Can it cause issues in HBase if we exclude netty-resolver-dns from Hadoop dependencies?
- Wouldn't be better solution to update the Netty version in Hadoop itself instead of excluding netty-resolver-dns here?
2 participants
No description provided.