On Mon, Nov 5, 2018 at 10:09 AM Sean Busbey <bus...@apache.org> wrote:
> 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? > > Sounds good. > What about dropping all the Hadoop 2's for HBase 3? (maybe a new thread? > :smile:) > > I wish. Yeah, another thread. S > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
