As of last week the Apache Hadoop project now keeps a public list of CVEs that 
are public. (although it's currently limited to things from the last year)

https://hadoop.apache.org/cve_list.html

Folks okay with linking to that page and updating Hadoop requirements for the 
next minor releases in 1.y and 2.y to be versions without something listed 
there?

What about dropping all the Hadoop 2's for HBase 3? (maybe a new thread? 
:smile:)

On 2018/10/24 15:21:32, Sean Busbey <bus...@apache.org> wrote: 
> FYI HADOOP-15878 is tracking publishing impacted versions for the CVE
> 
> On Tue, Oct 23, 2018 at 11:37 AM Sean Busbey <bus...@apache.org> wrote:
> >
> > I can get behind more aggressively updating our dependencies to avoid
> > CVEs. I don't think we should do this in maintenance releases though.
> > Maintenance releases are meant to be extremely low risk for downstream
> > users. Despite our efforts to date upgrading a dependency is still
> > disruptive, especially when it's Hadoop. CVEs carry with them a needed
> > context for something to be an issue. That context almost never covers
> > all possible deployment scenarios and we should leave it to downstream
> > users to decide if the risk / reward trade off of justifies the
> > dependency update. Asking folks who think the risk is worth it to bump
> > up a minor HBase version or patch their deployment locally is a
> > reasonable trade off IMHO.
> >
> > I think I have the Hadoop PMC on board for publicizing impacted
> > versions on CVE-2018-8009 specifically. Give me a couple of days to
> > get that out in whatever form so that everyone in this discussion has
> > a more level field?
> > On Mon, Oct 22, 2018 at 9:07 PM 张铎(Duo Zhang) <palomino...@gmail.com> wrote:
> > >
> > > I believe if there is a CVE for any of the dependencies we should try to
> > > upgrade it, and IIRC there is an issue about finding these dependencies 
> > > out
> > > automatically. We haven't done this before does not mean ignoring a CVE is
> > > the correct way, it is just because no one takes care of it...
> > >
> > > And the hadoop team has stated the versions which are vulnerable, all
> > > versions before 2.7.7, 2.8.5, 2.9.2(not released yet?), 3.0.3 and 3.1.1.
> > > Not sure if they have published this out to the public, but as you can see
> > > the url provided by me above, it is already public, so it does not matter
> > > whether the hadoop team has published or not...
> > >
> > > Sean Busbey <bus...@apache.org> 于2018年10月23日周二 上午9:50写道:
> > >
> > > > Has the Hadoop PMC put out a public notice on the impact of that CVE 
> > > > yet?
> > > > Specifically have they stated what versions are vulnerable? Are we 
> > > > flagging
> > > > all versions impacted by it as "HBase says keep away"?
> > > >
> > > > Is there some reason this particular CVE especially impacts users of 
> > > > HBase?
> > > > I presume not since we're talking about this on dev@ and in JIRA instead
> > > > of
> > > > on private@.
> > > >
> > > > Why are we reacting to this CVE when we don't seem to react to any other
> > > > Hadoop CVEs? Or is this the start of a change wrt that?
> > > >
> > > > What about other dependencies with open CVEs?
> > > >
> > > > On Mon, Oct 22, 2018, 20:33 张铎(Duo Zhang) <palomino...@gmail.com> wrote:
> > > >
> > > > > See here:
> > > > >
> > > > > https://access.redhat.com/security/cve/cve-2018-8009
> > > > >
> > > > > All 2.7.x releases before 2.7.7 have the problem. And for 2.6.x, the
> > > > hadoop
> > > > > team seems to drop the support as there is no release about two 
> > > > > years, so
> > > > > either we keep the original support versions, or we just drop the 
> > > > > support
> > > > > for the 2.6.x release line.
> > > > >
> > > > > Zach York <zyork.contribut...@gmail.com> 于2018年10月23日周二 上午8:51写道:
> > > > >
> > > > > > What is the main reason for the change? Build time speedup?
> > > > > >
> > > > > > Any reason for testing all of the 2.6.x line, but not the 2.7.x 
> > > > > > line?
> > > > We
> > > > > > don't check at all for 2.8.x?
> > > > > >
> > > > > > Can we be more consistent with how we test compatibility? (Do we 
> > > > > > only
> > > > > care
> > > > > > about the latest patch release in a line?)
> > > > > >
> > > > > > Sorry If I'm missing some of the reasoning, but at a surface level 
> > > > > > it
> > > > > seems
> > > > > > fairly arbitrary which releases we are cutting.
> > > > > >
> > > > > > On Mon, Oct 22, 2018 at 5:44 PM Sean Busbey <bus...@apache.org> 
> > > > > > wrote:
> > > > > >
> > > > > > > Please leave me time to review before it is committed.
> > > > > > >
> > > > > > > On Mon, Oct 22, 2018, 13:58 Stack <st...@duboce.net> wrote:
> > > > > > >
> > > > > > > > Duo has a patch up on HBASE-20970 that changes the Hadoop 
> > > > > > > > versions
> > > > we
> > > > > > > check
> > > > > > > > at build time. Any objections to committing to branch-2.1+?
> > > > > > > >
> > > > > > > > It makes following changes:
> > > > > > > >
> > > > > > > > 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 2.7.4
> > > > > > > >
> > > > > > > > becomes
> > > > > > > >
> > > > > > > > 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.7
> > > > > > > >
> > > > > > > > And...
> > > > > > > >
> > > > > > > > 3.0.0
> > > > > > > >
> > > > > > > > goes to
> > > > > > > >
> > > > > > > > 3.0.3
> > > > > > > >
> > > > > > > > Shout if you are against the change else will commit tomorrow.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > S
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> 

Reply via email to