We should do that bump to hbase-thirdparty and spin another release to keep our house in order. It isn’t urgent but would be good to address this in the normal release cadence. That has been about once per fiscal quarter recently. It’s weird to have netty dependency versions diverging.
I will make a note as RM to look at hbase-thirdparty versions with respect to the base POM and known security issues, using snyk probably, and update it ahead of 2.5.8. As well as direct dependencies in the base POM. Unfortunately I can’t promise to do anything about transitive issues imported from something that impacts operational compatibility. Those must be weighed case by case. > On Jan 4, 2024, at 8:31 AM, Bryan Beaudreault <bbeaudrea...@apache.org> wrote: > > It looks like that CVE only affects io.netty:netty-codec-http2. Since our > hbase-shaded-netty depends on netty-all, that module is included. However, > I don't think we use anything from netty-codec-http2. So I don't think the > CVE is a risk for this usage, unless you are building an app using the > org.apache.hbase.thirdparty.io.netty classes. This would not be advised. > > That said, we could try to bump hbase-thirdparty to 4.1.100+ and include > that in the upcoming 2.6.0 or 2.5.8 when that happens. If the CVE were > critical we could rush out another minor release, but I don't think it's > necessary here? I also wonder if we should update hbase-shaded-netty to > only pull in the netty modules we actually use. > >> On Thu, Jan 4, 2024 at 11:14 AM Dan Huff <dan.h...@dremio.com.invalid> >> wrote: >> >> Thanks Bryan. That does help explain things. I have been looking at >> https://github.com/netty/netty/security/advisories/GHSA-xpw8-rcwv-8f8p and >> have been trying to determine if hbase is vulnerable to this attack vector >> or not. I got excited when I saw 4.1.100.Final in 2.5.7 but it sounds like >> that excitement was misplaced :) >> >> Dan >> >> On Tue, Jan 2, 2024 at 12:54 PM Bryan Beaudreault <bbeaudrea...@apache.org >>> >> wrote: >> >>> Hello, >>> >>> As the comment above the netty version change says, this only affects the >>> transitive netty dependencies from thirdparty dependencies like zookeeper >>> and hadoop. HBase's internal netty usage (i.e. for HBase's RPC protocol) >>> uses the shaded netty provided by hbase-thirdparty. >>> >>> While you're generally correct that in maven you'd expect a version >> defined >>> in dependencyManagement to affect all transitive dependencies, that is >> not >>> the case for hbase-thirdparty due to the shading we do there. At the time >>> of building hbase-thirdparty, the defined netty version there is pulled >> in >>> and relocated to org.apache.hbase.thirdparty.io.netty and published as a >>> new maven module named hbase-shaded-netty. As such, the >>> dependencyManagement has no effect on it. >>> >>> I hope this helps >>> >>> On Tue, Jan 2, 2024 at 2:40 PM Dan Huff <dan.h...@dremio.com.invalid> >>> wrote: >>> >>>> Hello there Hbase Devs-- >>>> >>>> I have been investigating taking an update to Hbase 2.5.7 after the >>> release >>>> last week and have what I hope is a quick question about commit 7639345 >>>> < >>>> >>> >> https://github.com/apache/hbase/commit/7639345a970636e7a9eb7adf6d84dadd6f3fccb9 >>>>> >>>> in >>>> branch-2.5. >>>> >>>> Am I correct in believing that the direct inclusion of netty >>> 4.1.100.Final >>>> in Hbase's pom.xml will override the 4.1.97.Final version that is >>>> specified in hbase-thirdparty >>>> < >> https://github.com/apache/hbase-thirdparty/blob/rel/4.1.5/pom.xml#L137 >>>> ? >>>> I >>>> see 4.1.100.Final listed on >>>> https://hbase.apache.org/dependency-management.html which to me >> suggests >>>> that I am understanding this correctly that issues flagged against >>>> 4.1.97.Final can be ignored since Hbase will now just use >> 4.1.100.Final. >>>> >>>> Thanks so much for your time, >>>> >>>> Dan Huff >>>> >>> >>
