September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1883) Extend SASL protocol to handle Quality of Protection

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1883?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1883: ------------------------------------------- That isn't what I had in mind... and also there would have to be a lot of mechanism added to the protocol to make a scheme which reuses the SaslClient and SaslServer wrap/unwrap functions work in any case. What I had in mind is adding functionality to the JGroups SASL layer so that, from the outside, it looks and is configured as a regular SASL framework, supporting the QoP features mentioned above. Internally, it would bypass the SaslClient and SaslServer wrap/uwrap functions (which is what Tristan is referring to) and use the protocols and design of ENCRYPT to enforce integrity and confidentiality.. Otherwise, we will always be in the situation where we say "JGroups supports SASL" when in fact it does not; not in the sense that the QoP features of SASL are not there for use for *any* mechanism and we always have to add in an additional ENCRYPT layer to make up the shortfall on the integrity and confidentiality side. In that case, I don't see what the advantage of having a non fully-functional SASL layer is anyway. It seems like we want to move to a standard for configuring security, but not the whole way. As for David's remark, we could consider the shortcomings that he mentions and see to what extent they apply at present to ENCRYPT. Because as far as I understand it, ENCRYPT is basically SSL/TLS for JGroups. But that's potentially a separate issue. > Extend SASL protocol to handle Quality of Protection > ----------------------------------------------------- > > Key: JGRP-1883 > URL: https://issues.jboss.org/browse/JGRP-1883 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.5 > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.6 > > > SASL implementations generally provide authentication and encryption services to communication protocols. > At present, the JGroups SASL protocol layer handles only authentication of a client joining a group; it does not support encryption of messages (unicast and multicast) passing through the SASL layer. This is presently handled by the separate ENCRYPT layer. > It would be nice to provide an integrated and complete solution for authentication and encryption for JGroups based on SASL. This could be achieved by adding functionality from ENCRYPT to the SASL layer. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3902) Replace invalid RuntimePermissions with domain-specific permissions

by David Lloyd (JIRA)

David Lloyd created WFLY-3902: --------------------------------- Summary: Replace invalid RuntimePermissions with domain-specific permissions Key: WFLY-3902 URL: https://issues.jboss.org/browse/WFLY-3902 Project: WildFly Issue Type: Task Reporter: David Lloyd Assignee: David Lloyd Fix For: 9.0.0.CR1 Identify and if possible replace invalid usages of RuntimePermission in WildFly and its dependencies. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3901) Please add the "relative-to" attribute to access-log in undertow

by Carlton Zachary (JIRA)

Carlton Zachary created WFLY-3901: ------------------------------------- Summary: Please add the "relative-to" attribute to access-log in undertow Key: WFLY-3901 URL: https://issues.jboss.org/browse/WFLY-3901 Project: WildFly Issue Type: Feature Request Components: Web (Undertow) Affects Versions: 8.1.0.Final Reporter: Carlton Zachary Assignee: Stuart Douglas I have been trying to point the "directory" attribute value to a var ${custom.jboss.server.log.dir} to write the access.log to a non-default location, but this diesn't work in undertow. It does work in EAP 6.2 JBoss-web. The custom.jboss.server.log.dir is defined in the "<paths>" in the servers section of the host-slave.xml file. In JBoss EAP 6.2 with jboss-web the access-log has the "relative-to" attribute, but this is not the case with access-log for undertow in WFLY 8.1. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1880) UDP.ip_ttl is ignored and is always 1

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1880?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1880: -------------------------------- As we don't use DatagramChannel, there's no need to switch to JDK 7 as baseline. Reverted the changes in build.xml, pom.xml and TP to use JDK 6. > UDP.ip_ttl is ignored and is always 1 > ------------------------------------- > > Key: JGRP-1880 > URL: https://issues.jboss.org/browse/JGRP-1880 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.1, 3.6 > > > Since we switched from using a {{MulticastSocket}} for sending of multicast packets to a {{DatagramSocket}}, the time-to-live (TTL) of a packet is always {{1}}. The reason is that method {{setTimeToLive()}} only exists in {{MulticastSocket}}, but not in {{DatagramSocket}}. > We cannot revert the code and use a {{MulticastSocket}} to send multicasts, as this won't reveal the real IP address of the sender, but only the multicast address, and the real address is needed to drop packets at the _transport level_. > Investigate whether we could use reflection to get the {{DatagramSocketImpl}} and call {{setTimeToLive()}}. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-88) Release Remoting JMX 1.1.3.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/REMJMX-88?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on REMJMX-88: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1113249|https://bugzilla.redhat.com/show_bug.cgi?id=1113249] from POST to MODIFIED > Release Remoting JMX 1.1.3.Final > -------------------------------- > > Key: REMJMX-88 > URL: https://issues.jboss.org/browse/REMJMX-88 > Project: Remoting JMX > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.3.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-117) Typo in add-user help text

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-117?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-117: ------------------------------------------------ Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1145036|https://bugzilla.redhat.com/show_bug.cgi?id=1145036] from POST to MODIFIED > Typo in add-user help text > -------------------------- > > Key: WFCORE-117 > URL: https://issues.jboss.org/browse/WFCORE-117 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 1.0.0.Alpha8 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha9 > > > There is a typo in help message of add-user tool. > Version-Release number of selected component (if applicable): > EAP 6.4.0.DR1.1 > How reproducible: > Always > Steps to Reproduce: > 1. ./add-user.sh --help > Actual results: > ... > -sc <value> Define the location the server config > directory. > ... > Expected results: > ... > -sc <value> Define the location of the server config > directory. > ... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-124) The yes/no checking in add-user converts the users input to lower case but not the translated values.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-124?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-124: ------------------------------------------------ Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 901193|https://bugzilla.redhat.com/show_bug.cgi?id=901193] from POST to MODIFIED > The yes/no checking in add-user converts the users input to lower case but not the translated values. > ----------------------------------------------------------------------------------------------------- > > Key: WFCORE-124 > URL: https://issues.jboss.org/browse/WFCORE-124 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha9 > > > The end result is if the translated value contains upper case characters the users input will not match, as an example for German ja and Ja - whatever the user inputs it will be converted to 'ja' but is always compared to 'Ja'. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3888) Show more informations of a timer in ERROR/WARN messages to identify the failed timer exactly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3888?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3888: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1145896|https://bugzilla.redhat.com/show_bug.cgi?id=1145896] from NEW to MODIFIED > Show more informations of a timer in ERROR/WARN messages to identify the failed timer exactly > --------------------------------------------------------------------------------------------- > > Key: WFLY-3888 > URL: https://issues.jboss.org/browse/WFLY-3888 > Project: WildFly > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > All ERROR and WARN messages should show the full timer information, specially the customer timer-information. > This will make it more easy to identify the exact timer in case of an EJB object has multiple timer instances active. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2515) JBAS014249 if a fire and forget asynchronous ejb call is made

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2515?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2515: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1030936|https://bugzilla.redhat.com/show_bug.cgi?id=1030936] from ASSIGNED to MODIFIED > JBAS014249 if a fire and forget asynchronous ejb call is made > ------------------------------------------------------------- > > Key: WFLY-2515 > URL: https://issues.jboss.org/browse/WFLY-2515 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Beta1, 8.0.0.CR1 > Environment: Beta2 SNAPSHOT > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > > If an ejb method > @Asynchronous void fireAndForget(...) > is called remote and the client disconnect an Exception JBAS014249 will be thrown if the async method return. > {noformat} > ERROR [org.jboss.as.ejb3] (EJB default - 1) JBAS014249: Error invoking method public abstract void org.jboss.as.quickstarts.ejb.asynchronous.AsynchronousAccess.fireAndForget(long) on bean named AsynchronousAccessBean for appname modulename jboss-as-ejb-asynchronous-ejb distinctname : java.lang.NullPointerException > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:322) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25] > at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > 11:30:20,242 ERROR [org.jboss.as.ejb3] (EJB default - 1) JBAS014250: Could not write method invocation failure for method public abstract void org.jboss.as.quickstarts.ejb.asynchronous.AsynchronousAccess.fireAndForget(long) on bean named AsynchronousAccessBean for appname modulename jboss-as-ejb-asynchronous-ejb distinctname due to: java.io.IOException: JBAS014560: Could not open message outputstream for writing to Channel > at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler.writeException(AbstractMessageHandler.java:102) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$400(MethodInvocationMessageHandler.java:70) > at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:213) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25] > at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > Caused by: org.jboss.remoting3.NotOpenException: Writes closed > at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:112) > at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:301) > at org.jboss.as.ejb3.remote.protocol.versionone.ChannelAssociation.acquireChannelMessageOutputStream(ChannelAssociation.java:68) > at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler.writeException(AbstractMessageHandler.java:100) > ... 9 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3600) TransactionRolledbackException doesn't reference the originating runtime-exception

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3600?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3600: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1109153|https://bugzilla.redhat.com/show_bug.cgi?id=1109153] from NEW to MODIFIED > TransactionRolledbackException doesn't reference the originating runtime-exception > ---------------------------------------------------------------------------------- > > Key: WFLY-3600 > URL: https://issues.jboss.org/browse/WFLY-3600 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > > If a RuntimeException is thrown by a business method this gets lost during propagation to the client. > The client is not able in this case to react appropriate to the cause. > Similar issue was fixed for the Local invocation, see AS7-5432 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2014