Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
+1 Definitely valuable for HBase users to be aware of Hadoop CVEs. Peter On Tue, Nov 6, 2018 at 6:16 AM Stack wrote: > On Mon, Nov 5, 2018 at 10:09 AM Sean Busbey 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 wrote: > > > FYI HADOOP-15878 is tracking publishing impacted versions for the CVE > > > > > > On Tue, Oct 23, 2018 at 11:37 AM Sean Busbey > 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) > > > 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 于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) > > > 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 于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: > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
On Mon, Nov 5, 2018 at 10:09 AM Sean Busbey 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 wrote: > > FYI HADOOP-15878 is tracking publishing impacted versions for the CVE > > > > On Tue, Oct 23, 2018 at 11:37 AM Sean Busbey 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) > 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 于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) > 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 于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 > wrote: > > > > > > > > > > > > > > > Please leave me time to review before it is committed. > > > > > > > > > > > > > > > > On Mon, Oct 22, 2018, 13:58 Stack 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
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
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 wrote: > FYI HADOOP-15878 is tracking publishing impacted versions for the CVE > > On Tue, Oct 23, 2018 at 11:37 AM Sean Busbey 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) 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 于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) 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 于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 > > > > > > wrote: > > > > > > > > > > > > > Please leave me time to review before it is committed. > > > > > > > > > > > > > > On Mon, Oct 22, 2018, 13:58 Stack 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 > > > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
I hear what you're saying, but I'd also be pissed if we waste our own time dealing with Hadoop issues that have already been addressed. Just my feeling, but I think I'm distracting from the original question at this point. On 10/24/18 5:01 PM, Sean Busbey wrote: Yes, because they deployed when 2.6.5 wasn't the latest and they don't want to deal with the headaches of Hadoop upgrades. If we do only one, it should be the oldest IMHO. But if we're just talking about changing thing in new minor releases of HBase this is moot. We make 2.7.7 the minimum instead of 2.7.1, call out the need to check later release lines against that CVE, and move on. On Wed, Oct 24, 2018, 15:00 Josh Elser wrote: IMO -- for the 2.6 line, let's just use 2.6.latest (2.6.5). Hadoop seems to have moved beyond 2.6, it doesn't seem likely that we're creating a lot of value for our users. Would someone deploying a Hadoop 2.6 release seriously try a release other than the latest? On 10/22/18 9:32 PM, 张铎(Duo Zhang) 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 于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 wrote: Please leave me time to review before it is committed. On Mon, Oct 22, 2018, 13:58 Stack 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
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
Yes, because they deployed when 2.6.5 wasn't the latest and they don't want to deal with the headaches of Hadoop upgrades. If we do only one, it should be the oldest IMHO. But if we're just talking about changing thing in new minor releases of HBase this is moot. We make 2.7.7 the minimum instead of 2.7.1, call out the need to check later release lines against that CVE, and move on. On Wed, Oct 24, 2018, 15:00 Josh Elser wrote: > IMO -- for the 2.6 line, let's just use 2.6.latest (2.6.5). > > Hadoop seems to have moved beyond 2.6, it doesn't seem likely that we're > creating a lot of value for our users. Would someone deploying a Hadoop > 2.6 release seriously try a release other than the latest? > > On 10/22/18 9:32 PM, 张铎(Duo Zhang) 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 于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 wrote: > >> > >>> Please leave me time to review before it is committed. > >>> > >>> On Mon, Oct 22, 2018, 13:58 Stack 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 > > >>> > >> > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
IMO -- for the 2.6 line, let's just use 2.6.latest (2.6.5). Hadoop seems to have moved beyond 2.6, it doesn't seem likely that we're creating a lot of value for our users. Would someone deploying a Hadoop 2.6 release seriously try a release other than the latest? On 10/22/18 9:32 PM, 张铎(Duo Zhang) 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 于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 wrote: Please leave me time to review before it is committed. On Mon, Oct 22, 2018, 13:58 Stack 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
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
FYI HADOOP-15878 is tracking publishing impacted versions for the CVE On Tue, Oct 23, 2018 at 11:37 AM Sean Busbey 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) 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 于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) 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 于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 wrote: > > > > > > > > > > > Please leave me time to review before it is committed. > > > > > > > > > > > > On Mon, Oct 22, 2018, 13:58 Stack 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 > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
The current patch includes documentation changes that impact all versions, so we'll have to update for that. Happy to deal with those details on the JIRA though, if we have lazy consensus here on the overall approach. On Tue, Oct 23, 2018 at 3:11 PM Stack wrote: > > On Tue, Oct 23, 2018 at 9:44 AM Sean Busbey 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. > > > > > This seems reasonable to me. > > I'd apply HBASE-20970 to branch-2.2 and skip adding it on branch-2.1 since > we've pull a 2.1.0 from here already. > > Do we need to start our own little CVE poster board on the website? We > could use it to also point at similar in our dependencies. > > S > > > > > > 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) > > 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 于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) > > 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 于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 > > wrote: > > > > > > > > > > > > > Please leave me time to review before it is committed. > > > > > > > > > > > > > > On Mon, Oct 22, 2018, 13:58 Stack 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... > > > > > > > > > > > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
On Tue, Oct 23, 2018 at 9:44 AM Sean Busbey 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. > > This seems reasonable to me. I'd apply HBASE-20970 to branch-2.2 and skip adding it on branch-2.1 since we've pull a 2.1.0 from here already. Do we need to start our own little CVE poster board on the website? We could use it to also point at similar in our dependencies. S > 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) > 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 于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) > 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 于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 > wrote: > > > > > > > > > > > Please leave me time to review before it is committed. > > > > > > > > > > > > On Mon, Oct 22, 2018, 13:58 Stack 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 > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
Thanks for the context Duo! Yes I agree, if we know about a CVE for a dependency it is our duty to either upgrade the dependency or disclose the vulnerability (ReleaseNotes?) so that users can make the necessary decision. However, this obviously does not apply for any CVE that hasn't been brought to our attention. Just my 2 cents. Zach P.S. I am fine with the removal now that I have more context. On Tue, Oct 23, 2018 at 9:44 AM Sean Busbey 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) > 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 于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) > 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 于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 > wrote: > > > > > > > > > > > Please leave me time to review before it is committed. > > > > > > > > > > > > On Mon, Oct 22, 2018, 13:58 Stack 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 > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
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) 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 于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) 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 于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 wrote: > > > > > > > > > Please leave me time to review before it is committed. > > > > > > > > > > On Mon, Oct 22, 2018, 13:58 Stack 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 > > > > > > > > > > > > > > > > > > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
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 于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) 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 于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 wrote: > > > > > > > Please leave me time to review before it is committed. > > > > > > > > On Mon, Oct 22, 2018, 13:58 Stack 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 > > > > > > > > > > > > > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
We should react to all CVEs if we’re going to. Fine to start now. > On Oct 22, 2018, at 6:50 PM, Sean Busbey wrote: > > 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) 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 于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 wrote: Please leave me time to review before it is committed. > On Mon, Oct 22, 2018, 13:58 Stack 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 > >>> >>
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
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) 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 于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 wrote: > > > > > Please leave me time to review before it is committed. > > > > > > On Mon, Oct 22, 2018, 13:58 Stack 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 > > > > > > > > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
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 于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 wrote: > > > Please leave me time to review before it is committed. > > > > On Mon, Oct 22, 2018, 13:58 Stack 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 > > > > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
Zach you fine with conversation about this on the JIRA or you wanna do on the list? On Mon, Oct 22, 2018, 19:51 Zach York wrote: > 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 wrote: > > > Please leave me time to review before it is committed. > > > > On Mon, Oct 22, 2018, 13:58 Stack 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 > > > > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
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 wrote: > Please leave me time to review before it is committed. > > On Mon, Oct 22, 2018, 13:58 Stack 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 > > >
Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?
Please leave me time to review before it is committed. On Mon, Oct 22, 2018, 13:58 Stack 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 >
