Discussion:
[DISCUSS] Changing hadoop check versions in our hbase-personality?
(too old to reply)
Stack
2018-10-22 18:58:37 UTC
Permalink
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
Sean Busbey
2018-10-23 00:44:18 UTC
Permalink
Please leave me time to review before it is committed.
Post by Stack
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+?
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
Zach York
2018-10-23 00:51:13 UTC
Permalink
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.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop versions we
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Sean Busbey
2018-10-23 01:09:31 UTC
Permalink
Zach you fine with conversation about this on the JIRA or you wanna do on
the list?
Post by Zach York
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.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop versions we
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
张铎(Duo Zhang)
2018-10-23 01:32:51 UTC
Permalink
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.
Post by Zach York
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.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop versions we
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Sean Busbey
2018-10-23 01:50:03 UTC
Permalink
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 ***@.

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?
Post by 张铎(Duo Zhang)
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.
Post by Zach York
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
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface level it
seems
Post by Zach York
fairly arbitrary which releases we are cutting.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop versions we
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Andrew Purtell
2018-10-23 01:59:19 UTC
Permalink
We should react to all CVEs if we’re going to. Fine to start now.
Post by Sean Busbey
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?
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?
Post by 张铎(Duo Zhang)
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.
Post by Zach York
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
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface level it
seems
Post by Zach York
fairly arbitrary which releases we are cutting.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop versions we
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
张铎(Duo Zhang)
2018-10-23 02:07:35 UTC
Permalink
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...
Post by Sean Busbey
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?
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?
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
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.
Post by Zach York
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
Post by 张铎(Duo Zhang)
Post by Zach York
don't check at all for 2.8.x?
Can we be more consistent with how we test compatibility? (Do we only
care
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface level it
seems
Post by Zach York
fairly arbitrary which releases we are cutting.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop versions
we
Post by 张铎(Duo Zhang)
Post by Zach York
Post by Sean Busbey
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Sean Busbey
2018-10-23 16:37:23 UTC
Permalink
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?
Post by 张铎(Duo Zhang)
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...
Post by Sean Busbey
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?
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?
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
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.
Post by Zach York
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
Post by 张铎(Duo Zhang)
Post by Zach York
don't check at all for 2.8.x?
Can we be more consistent with how we test compatibility? (Do we only
care
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface level it
seems
Post by Zach York
fairly arbitrary which releases we are cutting.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop versions
we
Post by 张铎(Duo Zhang)
Post by Zach York
Post by Sean Busbey
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Zach York
2018-10-23 17:14:53 UTC
Permalink
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.
Post by Sean Busbey
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?
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
automatically. We haven't done this before does not mean ignoring a CVE
is
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
the url provided by me above, it is already public, so it does not matter
whether the hadoop team has published or not...
Post by Sean Busbey
Has the Hadoop PMC put out a public notice on the impact of that CVE
yet?
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Specifically have they stated what versions are vulnerable? Are we
flagging
Post by 张铎(Duo Zhang)
Post by Sean Busbey
all versions impacted by it as "HBase says keep away"?
Is there some reason this particular CVE especially impacts users of
HBase?
instead
Post by 张铎(Duo Zhang)
Post by Sean Busbey
of
Why are we reacting to this CVE when we don't seem to react to any
other
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Hadoop CVEs? Or is this the start of a change wrt that?
What about other dependencies with open CVEs?
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
team seems to drop the support as there is no release about two
years, so
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
either we keep the original support versions, or we just drop the
support
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
for the 2.6.x release line.
Post by Zach York
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?
Post by 张铎(Duo Zhang)
Post by Sean Busbey
We
Post by 张铎(Duo Zhang)
Post by Zach York
don't check at all for 2.8.x?
Can we be more consistent with how we test compatibility? (Do we
only
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
care
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface level
it
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
seems
Post by Zach York
fairly arbitrary which releases we are cutting.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop
versions
Post by 张铎(Duo Zhang)
Post by Sean Busbey
we
Post by 张铎(Duo Zhang)
Post by Zach York
Post by Sean Busbey
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Stack
2018-10-23 20:11:01 UTC
Permalink
Post by Sean Busbey
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
Post by Sean Busbey
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?
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
automatically. We haven't done this before does not mean ignoring a CVE
is
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
the url provided by me above, it is already public, so it does not matter
whether the hadoop team has published or not...
Post by Sean Busbey
Has the Hadoop PMC put out a public notice on the impact of that CVE
yet?
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Specifically have they stated what versions are vulnerable? Are we
flagging
Post by 张铎(Duo Zhang)
Post by Sean Busbey
all versions impacted by it as "HBase says keep away"?
Is there some reason this particular CVE especially impacts users of
HBase?
instead
Post by 张铎(Duo Zhang)
Post by Sean Busbey
of
Why are we reacting to this CVE when we don't seem to react to any
other
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Hadoop CVEs? Or is this the start of a change wrt that?
What about other dependencies with open CVEs?
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
team seems to drop the support as there is no release about two
years, so
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
either we keep the original support versions, or we just drop the
support
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
for the 2.6.x release line.
Post by Zach York
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?
Post by 张铎(Duo Zhang)
Post by Sean Busbey
We
Post by 张铎(Duo Zhang)
Post by Zach York
don't check at all for 2.8.x?
Can we be more consistent with how we test compatibility? (Do we
only
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
care
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface level
it
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
seems
Post by Zach York
fairly arbitrary which releases we are cutting.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop
versions
Post by 张铎(Duo Zhang)
Post by Sean Busbey
we
Post by 张铎(Duo Zhang)
Post by Zach York
Post by Sean Busbey
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Sean Busbey
2018-10-24 15:15:27 UTC
Permalink
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.
Post by Stack
Post by Sean Busbey
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
Post by Sean Busbey
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?
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
automatically. We haven't done this before does not mean ignoring a CVE
is
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
the url provided by me above, it is already public, so it does not matter
whether the hadoop team has published or not...
Post by Sean Busbey
Has the Hadoop PMC put out a public notice on the impact of that CVE
yet?
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Specifically have they stated what versions are vulnerable? Are we
flagging
Post by 张铎(Duo Zhang)
Post by Sean Busbey
all versions impacted by it as "HBase says keep away"?
Is there some reason this particular CVE especially impacts users of
HBase?
instead
Post by 张铎(Duo Zhang)
Post by Sean Busbey
of
Why are we reacting to this CVE when we don't seem to react to any
other
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Hadoop CVEs? Or is this the start of a change wrt that?
What about other dependencies with open CVEs?
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
team seems to drop the support as there is no release about two
years, so
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
either we keep the original support versions, or we just drop the
support
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
for the 2.6.x release line.
Post by Zach York
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?
Post by 张铎(Duo Zhang)
Post by Sean Busbey
We
Post by 张铎(Duo Zhang)
Post by Zach York
don't check at all for 2.8.x?
Can we be more consistent with how we test compatibility? (Do we
only
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
care
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface level
it
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
seems
Post by Zach York
fairly arbitrary which releases we are cutting.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop
versions
Post by 张铎(Duo Zhang)
Post by Sean Busbey
we
Post by 张铎(Duo Zhang)
Post by Zach York
Post by Sean Busbey
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Sean Busbey
2018-10-24 15:21:32 UTC
Permalink
FYI HADOOP-15878 is tracking publishing impacted versions for the CVE
Post by Sean Busbey
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?
Post by 张铎(Duo Zhang)
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...
Post by Sean Busbey
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?
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?
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
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.
Post by Zach York
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
Post by 张铎(Duo Zhang)
Post by Zach York
don't check at all for 2.8.x?
Can we be more consistent with how we test compatibility? (Do we only
care
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface level it
seems
Post by Zach York
fairly arbitrary which releases we are cutting.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop versions
we
Post by 张铎(Duo Zhang)
Post by Zach York
Post by Sean Busbey
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Sean Busbey
2018-11-05 18:09:15 UTC
Permalink
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:)
Post by Sean Busbey
FYI HADOOP-15878 is tracking publishing impacted versions for the CVE
Post by Sean Busbey
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?
Post by 张铎(Duo Zhang)
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...
Post by Sean Busbey
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?
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?
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
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.
Post by Zach York
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
Post by 张铎(Duo Zhang)
Post by Zach York
don't check at all for 2.8.x?
Can we be more consistent with how we test compatibility? (Do we only
care
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface level it
seems
Post by Zach York
fairly arbitrary which releases we are cutting.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop versions
we
Post by 张铎(Duo Zhang)
Post by Zach York
Post by Sean Busbey
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Stack
2018-11-06 05:16:32 UTC
Permalink
Post by Sean Busbey
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.
Post by Sean Busbey
What about dropping all the Hadoop 2's for HBase 3? (maybe a new thread? :smile:)
I wish.

Yeah, another thread.

S
Post by Sean Busbey
Post by Sean Busbey
FYI HADOOP-15878 is tracking publishing impacted versions for the CVE
Post by Sean Busbey
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?
Post by 张铎(Duo Zhang)
I believe if there is a CVE for any of the dependencies we should
try to
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
upgrade it, and IIRC there is an issue about finding these
dependencies out
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
automatically. We haven't done this before does not mean ignoring a
CVE is
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
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.
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Not sure if they have published this out to the public, but as you
can see
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
the url provided by me above, it is already public, so it does not
matter
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
whether the hadoop team has published or not...
Post by Sean Busbey
Has the Hadoop PMC put out a public notice on the impact of that
CVE yet?
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Specifically have they stated what versions are vulnerable? Are we
flagging
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
all versions impacted by it as "HBase says keep away"?
Is there some reason this particular CVE especially impacts users
of HBase?
instead
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
of
Why are we reacting to this CVE when we don't seem to react to any
other
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Hadoop CVEs? Or is this the start of a change wrt that?
What about other dependencies with open CVEs?
Post by 张铎(Duo Zhang)
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
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
hadoop
Post by 张铎(Duo Zhang)
team seems to drop the support as there is no release about two
years, so
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
either we keep the original support versions, or we just drop
the support
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
for the 2.6.x release line.
䞊午8:51写道
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Zach York
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?
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
We
Post by 张铎(Duo Zhang)
Post by Zach York
don't check at all for 2.8.x?
Can we be more consistent with how we test compatibility? (Do
we only
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
care
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface
level it
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
seems
Post by Zach York
fairly arbitrary which releases we are cutting.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop
versions
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
we
Post by 张铎(Duo Zhang)
Post by Zach York
Post by Sean Busbey
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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.
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Zach York
Post by Sean Busbey
Post by Stack
Thanks,
S
Peter Somogyi
2018-11-06 07:43:13 UTC
Permalink
+1 Definitely valuable for HBase users to be aware of Hadoop CVEs.

Peter
Post by Stack
Post by Sean Busbey
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.
Post by Sean Busbey
What about dropping all the Hadoop 2's for HBase 3? (maybe a new thread? :smile:)
I wish.
Yeah, another thread.
S
Post by Sean Busbey
Post by Sean Busbey
FYI HADOOP-15878 is tracking publishing impacted versions for the CVE
Post by Sean Busbey
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
Post by Sean Busbey
Post by Sean Busbey
Post by Sean Busbey
users. Despite our efforts to date upgrading a dependency is still
disruptive, especially when it's Hadoop. CVEs carry with them a
needed
Post by Sean Busbey
Post by Sean Busbey
Post by Sean Busbey
context for something to be an issue. That context almost never
covers
Post by Sean Busbey
Post by Sean Busbey
Post by Sean Busbey
all possible deployment scenarios and we should leave it to
downstream
Post by Sean Busbey
Post by Sean Busbey
Post by Sean Busbey
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
Post by Sean Busbey
Post by Sean Busbey
Post by Sean Busbey
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?
Post by 张铎(Duo Zhang)
I believe if there is a CVE for any of the dependencies we should
try to
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
upgrade it, and IIRC there is an issue about finding these
dependencies out
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
automatically. We haven't done this before does not mean ignoring a
CVE is
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
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
Post by Sean Busbey
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
versions before 2.7.7, 2.8.5, 2.9.2(not released yet?), 3.0.3 and
3.1.1.
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Not sure if they have published this out to the public, but as you
can see
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
the url provided by me above, it is already public, so it does not
matter
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
whether the hadoop team has published or not...
Post by Sean Busbey
Has the Hadoop PMC put out a public notice on the impact of that
CVE yet?
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Specifically have they stated what versions are vulnerable? Are
we
Post by Sean Busbey
flagging
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
all versions impacted by it as "HBase says keep away"?
Is there some reason this particular CVE especially impacts users
of HBase?
instead
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
of
Why are we reacting to this CVE when we don't seem to react to
any
Post by Sean Busbey
other
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Hadoop CVEs? Or is this the start of a change wrt that?
What about other dependencies with open CVEs?
Post by 张铎(Duo Zhang)
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,
Post by Sean Busbey
the
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
hadoop
Post by 张铎(Duo Zhang)
team seems to drop the support as there is no release about two
years, so
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
either we keep the original support versions, or we just drop
the support
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
for the 2.6.x release line.
䞊午8:51写道
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Zach York
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?
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
We
Post by 张铎(Duo Zhang)
Post by Zach York
don't check at all for 2.8.x?
Can we be more consistent with how we test compatibility? (Do
we only
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
care
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface
level it
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
seems
Post by Zach York
fairly arbitrary which releases we are cutting.
On Mon, Oct 22, 2018 at 5:44 PM Sean Busbey <
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop
versions
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
we
Post by 张铎(Duo Zhang)
Post by Zach York
Post by Sean Busbey
check
Post by Stack
at build time. Any objections to committing to
branch-2.1+?
Post by Sean Busbey
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Zach York
Post by Sean Busbey
Post by Stack
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.
Post by Sean Busbey
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Sean Busbey
Post by 张铎(Duo Zhang)
Post by Zach York
Post by Sean Busbey
Post by Stack
Thanks,
S
Josh Elser
2018-10-24 20:00:28 UTC
Permalink
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?
Post by 张铎(Duo Zhang)
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.
Post by Zach York
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.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop versions we
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Sean Busbey
2018-10-24 21:01:53 UTC
Permalink
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.
Post by Josh Elser
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?
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
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.
Post by Zach York
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
Post by 张铎(Duo Zhang)
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface level it
seems
Post by 张铎(Duo Zhang)
Post by Zach York
fairly arbitrary which releases we are cutting.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop versions we
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Josh Elser
2018-10-25 15:13:29 UTC
Permalink
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.
Post by Sean Busbey
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.
Post by Josh Elser
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?
Post by 张铎(Duo Zhang)
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
Post by 张铎(Duo Zhang)
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.
Post by Zach York
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
Post by 张铎(Duo Zhang)
Post by Zach York
about the latest patch release in a line?)
Sorry If I'm missing some of the reasoning, but at a surface level it
seems
Post by 张铎(Duo Zhang)
Post by Zach York
fairly arbitrary which releases we are cutting.
Post by Sean Busbey
Please leave me time to review before it is committed.
Post by Stack
Duo has a patch up on HBASE-20970 that changes the Hadoop versions we
check
Post by Stack
at build time. Any objections to committing to branch-2.1+?
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
Continue reading on narkive:
Loading...