July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-610) Missing null check in build() method of X509CertificateBuilder

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-610: -------------------------------- Summary: Missing null check in build() method of X509CertificateBuilder Key: ELY-610 URL: https://issues.jboss.org/browse/ELY-610 Project: WildFly Elytron Issue Type: Bug Affects Versions: 1.1.0.Beta7 Reporter: Ondrej Lukas Assignee: Darran Lofthouse Calling {{ASN1.oidFromSignatureAlgorithm(String)}} in {{org.wildfly.security.x500.cert.X509CertificateBuilder.build()}} method on line 375 [1] for unknown algorithms returns null which is assigned to {{signatureAlgorithmOid}} and results to NPE thrown from {{derEncoder.encodeObjectIdentifier(signatureAlgorithmOid)}} on line 377. [1] https://github.com/wildfly-security/wildfly-elytron/blob/e01a09572b02f33d... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-609) Unguarded read in ElytronPolicyConfiguration

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-609: -------------------------------- Summary: Unguarded read in ElytronPolicyConfiguration Key: ELY-609 URL: https://issues.jboss.org/browse/ELY-609 Project: WildFly Elytron Issue Type: Bug Affects Versions: 1.1.0.Beta7 Reporter: Ondrej Lukas Assignee: Darran Lofthouse Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6894) Upgrade to JBoss Negotiation 3.0.3.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-6894: -------------------------------------- Summary: Upgrade to JBoss Negotiation 3.0.3.Final Key: WFLY-6894 URL: https://issues.jboss.org/browse/WFLY-6894 Project: WildFly Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1103) FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1103?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1103: ------------------------------------- Also this commit is required for this fix https://github.com/droolsjbpm/drools/commit/fe4d08a0a > FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-1103 > URL: https://issues.jboss.org/browse/DROOLS-1103 > Project: Drools > Issue Type: Bug > Affects Versions: 6.3.0.Final, 6.4.0.Final > Reporter: Juan Carlos Garcia > Assignee: Mario Fusco > Fix For: 7.0.0.Beta2 > > Attachments: RejectedExecutionExceptionBugReport.zip > > > Under very rare circumstance we have found the following exception *java.util.concurrent.RejectedExecutionException* in our production log. > Our guess is that the Drools Session is on its way to be dispose, while a new incoming request is in the middle of a fireAllRules operation (race condition). > I will try to provide a reproducible testcase for this. > {code} > Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@3e896443 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@71cc2f4c[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) > at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326) > at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:549) > at org.drools.core.time.impl.JDKTimerService.internalSchedule(JDKTimerService.java:118) > at org.drools.core.time.impl.JDKTimerService.scheduleJob(JDKTimerService.java:101) > at org.drools.core.phreak.PhreakTimerNode.scheduleTimer(PhreakTimerNode.java:304) > at org.drools.core.phreak.PhreakTimerNode.scheduleLeftTuple(PhreakTimerNode.java:233) > at org.drools.core.phreak.PhreakTimerNode.doLeftUpdates(PhreakTimerNode.java:131) > at org.drools.core.phreak.PhreakTimerNode.doNode(PhreakTimerNode.java:65) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:357) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200) > at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:957) > at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:260) > at XXXXXX.XXXXX.XXXXX.processEventDrools(EventProcessorImpl.java:128) > at XXXXXX.XXXXX.XXXXX.processEvent(EventProcessorImpl.java:101) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1592) PropertiesFileLoader persists entries after deletion

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1592?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-1592: ------------------------------------------ No there is nothing in the console that touches the users. > PropertiesFileLoader persists entries after deletion > ---------------------------------------------------- > > Key: WFCORE-1592 > URL: https://issues.jboss.org/browse/WFCORE-1592 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.Final, 2.2.0.CR1, 2.2.0.CR2, 3.0.0.Alpha1 > Reporter: Max Barkley > Assignee: Ken Wills > Fix For: 3.0.0.Alpha4, 2.2.0.Final > > > There is a bug in PropertiesFileLoader#persistProperties, specifically [here|https://github.com/wildfly/wildfly-core/blob/master/domain-managemen...]. Because of the write call in the else block, properties are persisted to the file even after they have been deleted in memory. > [Here|https://github.com/psiroky/uberfire/blob/2811baeac64805646d3943a096e...] is a fixed implementation of persistProperties that we are using as a workaround. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1679) jconsole wildfly cli tab plugin not reacting to connect/disconnect button

by Enrique González Martínez (JIRA)

Enrique González Martínez created WFCORE-1679: ------------------------------------------------- Summary: jconsole wildfly cli tab plugin not reacting to connect/disconnect button Key: WFCORE-1679 URL: https://issues.jboss.org/browse/WFCORE-1679 Project: WildFly Core Issue Type: Bug Reporter: Enrique González Martínez The current plugin does not reac to the connect/dissconnect button. causing an error in the next use case: 1) loing 2) show the jconsole tb 3) disconnect jconsole 4) connect jconsole again try to execute anything jconsole tab plugin -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

by Neal Dillman (JIRA)

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Neal Dillman commented on JGRP-2080: ------------------------------------ These changes can and probably should affect various parts of the system. We are doing what we can in our stack to minimize additional discovery traffic, but there is only so much that can be done without major overhaul (ie: 4.0). We did implement a new version of PING called LESS_PING that extends PING as we no longer need to have discovery run other than initial_discovery. It might also be good to get discovery our of MERGE[N], as that appears to be duplication (with PING/Discovery) and should not be needed for Merger. > New Address which contains IP address and port > ---------------------------------------------- > > Key: JGRP-2080 > URL: https://issues.jboss.org/browse/JGRP-2080 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol. > If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings. > An {{IPv4UUID}} (credits to Neal Dillman) would look like this: > * 4 bytes: IPv4 address > * 2 bytes: port > * 12 bytes: random data (rest of the UUID) > When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too. > When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately. > An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

by Neal Dillman (JIRA)

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Neal Dillman commented on JGRP-2080: ------------------------------------ Agree 100% about RELAY2 being critical. However, I believe it uses ExtendedUUID and so would not have the issue. > New Address which contains IP address and port > ---------------------------------------------- > > Key: JGRP-2080 > URL: https://issues.jboss.org/browse/JGRP-2080 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol. > If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings. > An {{IPv4UUID}} (credits to Neal Dillman) would look like this: > * 4 bytes: IPv4 address > * 2 bytes: port > * 12 bytes: random data (rest of the UUID) > When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too. > When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately. > An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2080: -------------------------------- RELAY2 (used for data center replication by Infinispan) installs its own generator, and that's a big use case for us. > New Address which contains IP address and port > ---------------------------------------------- > > Key: JGRP-2080 > URL: https://issues.jboss.org/browse/JGRP-2080 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol. > If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings. > An {{IPv4UUID}} (credits to Neal Dillman) would look like this: > * 4 bytes: IPv4 address > * 2 bytes: port > * 12 bytes: random data (rest of the UUID) > When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too. > When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately. > An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

by Neal Dillman (JIRA)

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Neal Dillman commented on JGRP-2080: ------------------------------------ In our scenario there is only one address generator installed (IPv4UUID). I believe that under most circumstances the limitation of ExtendedUUID being required for subsequent generators is acceptable [although that may be because I see limited use for additional generators]. > New Address which contains IP address and port > ---------------------------------------------- > > Key: JGRP-2080 > URL: https://issues.jboss.org/browse/JGRP-2080 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol. > If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings. > An {{IPv4UUID}} (credits to Neal Dillman) would look like this: > * 4 bytes: IPv4 address > * 2 bytes: port > * 12 bytes: random data (rest of the UUID) > When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too. > When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately. > An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016