Since we are planning a new thirdparty release, IMO we also put https://issues.apache.org/jira/browse/HBASE-28279, which bumps to latest jetty. Package jetty-http, that we bundle ( https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-http/9.4.52.v20230823), has a direct CVE https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36478
Regards, Nihal On Fri, 5 Jan 2024, 02:43 Andrew Purtell, <apurt...@apache.org> wrote: > Sounds good. I think we agree on everything. > > On Thu, Jan 4, 2024 at 12:37 PM Bryan Beaudreault <bbeaudrea...@apache.org > > > wrote: > > > To clarify, I was referring to "It’s weird to have netty dependency > > versions diverging." Which I do agree with, but was explaining my > > understanding of the rationale. > > > > Otherwise, I agree with everything else. I have the PR ready for updating > > netty in hbase-thirdparty. I can also vote and do the bump of > > hbase-thirdparty.version in hbase once the release is made. > > > > On Thu, Jan 4, 2024 at 3:15 PM Andrew Purtell <apurt...@apache.org> > wrote: > > > > > We should not ship a netty with known CVEs in hbase-thirdparty. > Likewise > > > for the other components shipped in hbase-thirdparty. As with all > things > > > this is a guideline, not a rule, because each situation is different > and > > > people do not always share the same opinion. > > > > > > I am of the opinion that moderate to high scoring CVEs in a dependency > -- > > > and it doesn't matter if direct, transitive, or shaded -- is going to > be > > a > > > problem for many users or potential users simply if they exist in our > > bill > > > of materials. At my employer we need to juggle the "cleanliness" of our > > > software bill of materials among priorities and I do not think we are > > > exceptional in any way. We do it in a fork but I have been meaning to > do > > a > > > pass over the public open source project's dependency set, if this > would > > > have some value for the project (which I believe there is). > > > > > > I can do a thirdparty release now if everyone else is busy. > > > > > > On Thu, Jan 4, 2024 at 10:50 AM Bryan Beaudreault < > > bbeaudrea...@apache.org > > > > > > > wrote: > > > > > > > I think we explicitly don't want our hbase-thirdparty netty version > to > > be > > > > locked to the one for transitive dependencies. That's sort of why we > > have > > > > it in thirdparty/shaded at all, right? > > > > > > > > I created https://issues.apache.org/jira/browse/HBASE-28291 to > update > > > > pom.xml in hbase-thirdparty. I will handle that. We will need to do > an > > > > hbase-thirdparty release, which I'm not sure I'll have time for given > > I'm > > > > already behind on the 2.6.0 release > > > > > > > > On Thu, Jan 4, 2024 at 11:58 AM Andrew Purtell < > > andrew.purt...@gmail.com > > > > > > > > wrote: > > > > > > > > > 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 > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Andrew > > > > > > Unrest, ignorance distilled, nihilistic imbeciles - > > > It's what we’ve earned > > > Welcome, apocalypse, what’s taken you so long? > > > Bring us the fitting end that we’ve been counting on > > > - A23, Welcome, Apocalypse > > > > > > > > -- > Best regards, > Andrew > > Unrest, ignorance distilled, nihilistic imbeciles - > It's what we’ve earned > Welcome, apocalypse, what’s taken you so long? > Bring us the fitting end that we’ve been counting on > - A23, Welcome, Apocalypse >
