Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -1875,6 +1875,25 @@
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
<version>${netty4.version}</version>
Comment on lines +1878 to +1881

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

<exclusions>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-resolver-dns</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-resolver-dns-classes-macos</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-resolver-dns-native-macos</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson</groupId>
<artifactId>jackson-bom</artifactId>
Expand Down Expand Up @@ -3665,6 +3684,10 @@
<groupId>org.slf4j</groupId>
<artifactId>slf4j-reload4j</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-resolver-dns</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
Expand Down Expand Up @@ -3840,6 +3863,10 @@
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-resolver-dns</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
Expand Down Expand Up @@ -3897,6 +3924,10 @@
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-resolver-dns</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
Expand Down