[jira] [Commented] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602568#comment-17602568
]
Owen Nichols commented on GEODE-10415:
--
Please note _any_ change to jgroups version will break ability to upgrade a
running Geode cluster with no downtime. Might be worth discussing that tradeoff
on the dev list first...it's hard to say whether security or downtime are of
greater importance to all Geode users.
The Spring CVE is not something that can be fixed by upgrading. More details
from the spring team here:
https://github.com/spring-projects/spring-framework/issues/24434#issuecomment-744519525
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Weijie Xu
>Priority: Blocker
> Labels: needsTriage
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602560#comment-17602560
]
Kirk Lund commented on GEODE-10415:
---
All of these issues should be resolvable by bumping dependencies.
* JGroups
[GHSA-rc7h-x6cq-988q|https://deps.dev/advisory/ghsa/GHSA-rc7h-x6cq-988q] aka
[CVE-2016-2141|https://nvd.nist.gov/vuln/detail/CVE-2016-2141] refers to
“Improper Input Validation in JGroups”
* Jetty [CVE-2022-2048|https://nvd.nist.gov/vuln/detail/CVE-2022-2048] refers
to “An invalid HTTP/2 request that can be used for Denial of Service”
* Shiro [CVE-2022-32532|https://nvd.nist.gov/vuln/detail/CVE-2022-32532] refers
to “RegexRequestMatcher misconfigured resulting in bypassing authorization”
* Spring [CVE-2016-127|https://nvd.nist.gov/vuln/detail/CVE-2016-127]
refers to “Potential RCE for Java deserialization of untrusted data” (sound
familiar?)
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Weijie Xu
>Priority: Blocker
> Labels: needsTriage
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602556#comment-17602556
]
Alexander Murmann commented on GEODE-10415:
---
Hi [~WeijieEST]. I think this one should just be a dependency update. Since you
volunteered on the mailing list to bump dependencies, I figured it might make
sense to assign this to you, so that you can resolve it once you bumped
versions. Please feel of course free to unassign if this didn't make sense.
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Weijie Xu
>Priority: Blocker
> Labels: needsTriage
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-10415:
-
Assignee: Weijie Xu (was: Kirk Lund)
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Weijie Xu
>Priority: Blocker
> Labels: needsTriage
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10249) Add stats for BufferPoolMXBean
[ https://issues.apache.org/jira/browse/GEODE-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10249: -- Fix Version/s: (was: 1.15.1) > Add stats for BufferPoolMXBean > -- > > Key: GEODE-10249 > URL: https://issues.apache.org/jira/browse/GEODE-10249 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > > Java provides information on buffer pools used in the JVM via > BufferPoolMXBean. Add the output of these to the basic set of platform stats > to diagnose buffer pool issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10144: -- Fix Version/s: (was: 1.15.1) > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server, native client >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: NativeClient > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-9296) CI Failure: PutAllClientServerDistributedTest > testPartialKeyInPRSingleHopWithRedundancy
[ https://issues.apache.org/jira/browse/GEODE-9296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9296: - Fix Version/s: (was: 1.15.1) > CI Failure: PutAllClientServerDistributedTest > > testPartialKeyInPRSingleHopWithRedundancy > - > > Key: GEODE-9296 > URL: https://issues.apache.org/jira/browse/GEODE-9296 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.15.0 >Reporter: Hale Bales >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI > > org.apache.geode.internal.cache.PutAllClientServerDistributedTest > > testPartialKeyInPRSingleHopWithRedundancy FAILED > org.junit.ComparisonFailure: expected:<[20]0> but was:<[17]0> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testPartialKeyInPRSingleHopWithRedundancy(PutAllClientServerDistributedTest.java:2430) > failed in CI run: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253#B > artifacts available here: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0251/test-results/distributedTest/1621568801/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEODE-10335) TXManagerImpl.close does not remove itself from the static singeton
[ https://issues.apache.org/jira/browse/GEODE-10335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602325#comment-17602325 ] ASF subversion and git services commented on GEODE-10335: - Commit ac8b1786ac5b70e1e252de9726ddcb0a927705d7 in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ac8b1786ac ] GEODE-10335_1: add compareAndSet (#7850) > TXManagerImpl.close does not remove itself from the static singeton > --- > > Key: GEODE-10335 > URL: https://issues.apache.org/jira/browse/GEODE-10335 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: blocks-1.16.0, pull-request-available > Fix For: 1.16.0 > > > TXManagerImpl.close does not remove itself from the static singleton. This > causes it to keep the GemFireCacheImpl alive after it has been closed. > The simple fix is to add "currentInstance = null" at the end of the close > method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GEODE-8971) Batches with incomplete transactions when stopping the gateway sender
[ https://issues.apache.org/jira/browse/GEODE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-8971. -- Resolution: Won't Fix > Batches with incomplete transactions when stopping the gateway sender > - > > Key: GEODE-8971 > URL: https://issues.apache.org/jira/browse/GEODE-8971 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.14.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When the gateway sender is stopped there is a high probability that batches > with incomplete transactions are sent even if group-transaction-events is > enabled. > The reason is that once the stop command reaches the gateway sender, it > immediately stops queueing events, and this could happen in the middle of > receiving events for the same transaction. If this is the case, some events > for the transaction may have reached the queue right before the stop command > was received and the rest of events for that transaction would not make it to > the queue (they would be dropped) because they arrived right after the stop > command was received at the gateway sender. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (GEODE-8971) Batches with incomplete transactions when stopping the gateway sender
[ https://issues.apache.org/jira/browse/GEODE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reopened GEODE-8971: -- This issue is reopened in order to state that it will not be solved because the solution provided (as it can be seen in the latest PR that reverts the proposed solution), creates a bigger problem than what it is trying to solve. > Batches with incomplete transactions when stopping the gateway sender > - > > Key: GEODE-8971 > URL: https://issues.apache.org/jira/browse/GEODE-8971 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.14.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When the gateway sender is stopped there is a high probability that batches > with incomplete transactions are sent even if group-transaction-events is > enabled. > The reason is that once the stop command reaches the gateway sender, it > immediately stops queueing events, and this could happen in the middle of > receiving events for the same transaction. If this is the case, some events > for the transaction may have reached the queue right before the stop command > was received and the rest of events for that transaction would not make it to > the queue (they would be dropped) because they arrived right after the stop > command was received at the gateway sender. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GEODE-10336) ConnectionTable.close does not null out its static lastInstance field
[ https://issues.apache.org/jira/browse/GEODE-10336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac resolved GEODE-10336. -- Fix Version/s: 1.16.0 Resolution: Fixed > ConnectionTable.close does not null out its static lastInstance field > - > > Key: GEODE-10336 > URL: https://issues.apache.org/jira/browse/GEODE-10336 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: blocks-1.16.0, pull-request-available > Fix For: 1.16.0 > > > The ConnectionTable.close method does a bunch of work but it does not null > out the static "lastInstance" atomic. This causes it to keep the > ConnectionTable alive which ends up keeping the InternalDistributedSystem > alive. > The easiest fix is to do this at the end of close: "emergencyClose();". The > emergencyClose correctly set the lastInstance atomic to null. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEODE-10336) ConnectionTable.close does not null out its static lastInstance field
[ https://issues.apache.org/jira/browse/GEODE-10336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602139#comment-17602139 ] ASF subversion and git services commented on GEODE-10336: - Commit c4ab763dea39328ba276e8c527bf531050f20cde in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c4ab763dea ] GEODE-10336: set lastInstance to null (#7843) * GEODE-10336: set lastInstance to null * GEODE-10336: added test > ConnectionTable.close does not null out its static lastInstance field > - > > Key: GEODE-10336 > URL: https://issues.apache.org/jira/browse/GEODE-10336 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: blocks-1.16.0, pull-request-available > > The ConnectionTable.close method does a bunch of work but it does not null > out the static "lastInstance" atomic. This causes it to keep the > ConnectionTable alive which ends up keeping the InternalDistributedSystem > alive. > The easiest fix is to do this at the end of close: "emergencyClose();". The > emergencyClose correctly set the lastInstance atomic to null. -- This message was sent by Atlassian Jira (v8.20.10#820010)
