July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1283) Channel binding SASL mechanisms should be preferred by Elytron clients

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1283?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on ELY-1283: ---------------------------------- Given the RFC language, I think that makes sense Farah. > Channel binding SASL mechanisms should be preferred by Elytron clients > ---------------------------------------------------------------------- > > Key: ELY-1283 > URL: https://issues.jboss.org/browse/ELY-1283 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Farah Juma > Priority: Critical > > The *\*-PLUS* SASL mechanisms (i.e. variants with channel binding) should be preferred by Elytron over the non-plus ones. > The channel binding [RFC-5056|https://tools.ietf.org/html/rfc5056#section-2.1] in section 2.1 states: > {noformat} > * If the authentication protocol used by the application supports > channel binding, the application SHOULD use it. > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1283) Channel binding SASL mechanisms should be preferred by Elytron clients

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-1283?page=com.atlassian.jira.plugin.s... ] Farah Juma commented on ELY-1283: --------------------------------- In [RFC-5802 Section 6|https://tools.ietf.org/html/rfc5802#section-6], it says that both the PLUS and non-PLUS mechanisms should be offered when channel binding is supported. We're currently offering the mechanisms in the following order, which is what's causing the non-PLUS mechanisms to get attempted first: {code} SCRAM_SHA_1 SCRAM_SHA_1_PLUS SCRAM_SHA_256 SCRAM_SHA_256_PLUS SCRAM_SHA_384 SCRAM_SHA_384_PLUS SCRAM_SHA_512 SCRAM_SHA_512_PLUS {code} I think we should change this order so that the PLUS mechanisms are offered first, as shown below. WDYT? {code} SCRAM_SHA_1_PLUS SCRAM_SHA_256_PLUS SCRAM_SHA_384_PLUS SCRAM_SHA_512_PLUS SCRAM_SHA_1 SCRAM_SHA_256 SCRAM_SHA_384 SCRAM_SHA_512 {code} > Channel binding SASL mechanisms should be preferred by Elytron clients > ---------------------------------------------------------------------- > > Key: ELY-1283 > URL: https://issues.jboss.org/browse/ELY-1283 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Farah Juma > Priority: Critical > > The *\*-PLUS* SASL mechanisms (i.e. variants with channel binding) should be preferred by Elytron over the non-plus ones. > The channel binding [RFC-5056|https://tools.ietf.org/html/rfc5056#section-2.1] in section 2.1 states: > {noformat} > * If the authentication protocol used by the application supports > channel binding, the application SHOULD use it. > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3061) On Windows, when running standalone/Domain with the JAVA_HOME environment variable set (but pointing to an empty directory), JBoss EAP fails to start and does not give an error message.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3061?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-3061: ------------------------------------------------- Fedor Gavrilov <fgavrilo(a)redhat.com> changed the Status of [bug 1459769|https://bugzilla.redhat.com/show_bug.cgi?id=1459769] from POST to MODIFIED > On Windows, when running standalone/Domain with the JAVA_HOME environment variable set (but pointing to an empty directory), JBoss EAP fails to start and does not give an error message. > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3061 > URL: https://issues.jboss.org/browse/WFCORE-3061 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Environment: Windows > Reporter: Durgesh Anaokar > Assignee: Durgesh Anaokar > Priority: Minor > Fix For: 3.0.0.Beta29 > > > On Windows 7, when running standalone.bat with the JAVA_HOME environment variable set (but pointing to an empty directory), JBoss EAP fails to start and does not give an error message. > On line 177 of the standalone.bat, a check is made to see if the JAVA_HOME variable points to a valid directory. If it does, it assumes this directory contains bin\java. If bin\java does not exist, the server fails to start and does not give a reason why. > expect to see an error message such as "%JAVA_HOME% path doesn't contain an executable at %JAVA_HOME%\bin\java" > Add additional checks in the standalone.conf to verify that %JAVA_HOME%\bin\java exists and warn if it does not. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1080) MDC is lost during @Asynchronous EJB calls

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1080?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1080: ----------------------------------------------- Fedor Gavrilov <fgavrilo(a)redhat.com> changed the Status of [bug 1464134|https://bugzilla.redhat.com/show_bug.cgi?id=1464134] from POST to MODIFIED > MDC is lost during @Asynchronous EJB calls > ------------------------------------------ > > Key: WFLY-1080 > URL: https://issues.jboss.org/browse/WFLY-1080 > Project: WildFly > Issue Type: Feature Request > Components: Logging > Reporter: Patrick Ruckstuhl > Assignee: David Lloyd > Fix For: 8.0.0.Alpha2 > > > If I set a variable into the MDC, this is propagated fine through to synchronous EJB calls, but is lost in asynchronous EJB calls. > Should the MDC not be copied over to the thread retrieved from the thread pool? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-139) Targetted refresh - MIQ Sprint-64

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-139?page=com.atlassian.jira.pl... ] Hayk Hovsepyan updated HAWKULARQE-139: -------------------------------------- Description: Summary: Enhancement for updating the status of deployments and servers frequently without the need in manual refresh Slide Deck: Slide-Deck: https://www.slideshare.net/ManageIQ/sprint-64 PR: https://github.com/ManageIQ/manageiq-providers-hawkular/pull/27 Decrease the waiting times for deployments appearance in CFME Tests. was: Summary: Enhancement for updating the status of deployments and servers frequently without the need in manual refresh Slide Deck: Slide-Deck: https://www.slideshare.net/ManageIQ/sprint-64 PR: https://github.com/ManageIQ/manageiq-providers-hawkular/pull/27 > Targetted refresh - MIQ Sprint-64 > --------------------------------- > > Key: HAWKULARQE-139 > URL: https://issues.jboss.org/browse/HAWKULARQE-139 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Hayk Hovsepyan > > Summary: Enhancement for updating the status of deployments and servers frequently without the need in manual refresh > Slide Deck: Slide-Deck: https://www.slideshare.net/ManageIQ/sprint-64 > PR: https://github.com/ManageIQ/manageiq-providers-hawkular/pull/27 > Decrease the waiting times for deployments appearance in CFME Tests. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1283) Channel binding SASL mechanisms should be preferred by Elytron clients

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1283?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on ELY-1283: ---------------------------------- The right approach for this might be for the SASL server and client factories to _only_ offer PLUS mechanisms when binding data is available, and _only_ offer non-PLUS when it is not. > Channel binding SASL mechanisms should be preferred by Elytron clients > ---------------------------------------------------------------------- > > Key: ELY-1283 > URL: https://issues.jboss.org/browse/ELY-1283 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Farah Juma > Priority: Critical > > The *\*-PLUS* SASL mechanisms (i.e. variants with channel binding) should be preferred by Elytron over the non-plus ones. > The channel binding [RFC-5056|https://tools.ietf.org/html/rfc5056#section-2.1] in section 2.1 states: > {noformat} > * If the authentication protocol used by the application supports > channel binding, the application SHOULD use it. > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1662) Fix docs.drools.org/latest and docs.drools.org/latestFinal

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1662?page=com.atlassian.jira.plugi... ] Michael Biarnes Kiefer commented on DROOLS-1662: ------------------------------------------------ for me they are working :) > Fix docs.drools.org/latest and docs.drools.org/latestFinal > ---------------------------------------------------------- > > Key: DROOLS-1662 > URL: https://issues.jboss.org/browse/DROOLS-1662 > Project: Drools > Issue Type: Task > Components: build > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Minor > > These work: docs.optaplanner.org/latest and docs.optaplanner.org/latestFinal > These don't: docs.drools.org/latest and docs.drools.org/latestFinal > (jbpm ones probably neither) > I think I vaguely remember fixing that for optaplanner.org by asking Vladamir of jbossorg. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (JBJCA-1352) IBM MQ deadlock on shutdown

by Flavia Rainone (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1352?page=com.atlassian.jira.plugin... ] Flavia Rainone reassigned JBJCA-1352: ------------------------------------- Assignee: Flavia Rainone > IBM MQ deadlock on shutdown > --------------------------- > > Key: JBJCA-1352 > URL: https://issues.jboss.org/browse/JBJCA-1352 > Project: IronJacamar > Issue Type: Bug > Components: AS > Affects Versions: WildFly/IronJacamar 1.4.2.Final > Environment: JBoss EAP 7.0.4 > Reporter: Doug Grove > Assignee: Flavia Rainone > > Sporadically, on shut down, IBM MQ and JBoss will deadlock. This does not occur on EAP 6. > The Deadlocking threads are > [1] > ~~~ > ServerService Thread Pool -- 63" #183 prio=5 os_prio=0 tid=0x00000000021ef800 nid=0x50e2 waiting for monitor entry [0x00007fef8451a000] > java.lang.Thread.State: BLOCKED (on object monitor) > at com.ibm.mq.connector.outbound.ConnectionEventHandler.removeListener(ConnectionEventHandler.java:93) > - waiting to lock <0x000000009be01318> (a com.ibm.mq.connector.outbound.ConnectionEventHandler) > at com.ibm.mq.connector.outbound.ManagedConnectionImpl.removeConnectionEventListener(ManagedConnectionImpl.java:434) > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.doDestroy(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1376) > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.flush(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:882) > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.shutdown(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1065) > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.shutdown(AbstractPool.java:930) > - locked < 0x000000008d09b340> (a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool) > at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.shutdown(AbstractConnectionManager.java:285) > - locked < 0x000000008d09b2e0> (a org.jboss.jca.core.connectionmanager.notx.NoTxConnectionManagerImpl) > at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService.unregisterAll(AbstractResourceAdapterDeploymentService.java:192) > at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService$3.run(AbstractResourceAdapterDeploymentService.java:346) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > ~~~ > [2] > ~~~ > "DefaultMessageListenerContainer-2" #162 prio=5 os_prio=0 tid=0x0000000001d7a800 nid=0x46bf waiting for monitor entry [0x00007fef70a7d000] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.shutdown(AbstractConnectionManager.java:281) > - waiting to lock <0x000000008d09b2e0> (a org.jboss.jca.core.connectionmanager.notx.NoTxConnectionManagerImpl) > at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.returnManagedConnection(AbstractConnectionManager.java:724) > at org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener.connectionClosed(NoTxConnectionListener.java:93) > at com.ibm.mq.connector.outbound.ConnectionEventHandler.fireEvent(ConnectionEventHandler.java:135) > - locked < 0x000000009be01318> (a com.ibm.mq.connector.outbound.ConnectionEventHandler) > at com.ibm.mq.connector.outbound.ManagedConnectionImpl.fireConnectionClosed(ManagedConnectionImpl.java:784) > at com.ibm.mq.connector.outbound.ConnectionWrapper.close(ConnectionWrapper.java:337) > at org.springframework.jms.connection.ConnectionFactoryUtils.releaseConnection(ConnectionFactoryUtils.java:80) > at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:358) > at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:255) > at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1166) > at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1158) > at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1055) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1283) Channel binding SASL mechanisms should be preferred by Elytron clients

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-1283?page=com.atlassian.jira.plugin.s... ] Farah Juma reassigned ELY-1283: ------------------------------- Assignee: Farah Juma (was: Darran Lofthouse) > Channel binding SASL mechanisms should be preferred by Elytron clients > ---------------------------------------------------------------------- > > Key: ELY-1283 > URL: https://issues.jboss.org/browse/ELY-1283 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Farah Juma > Priority: Critical > > The *\*-PLUS* SASL mechanisms (i.e. variants with channel binding) should be preferred by Elytron over the non-plus ones. > The channel binding [RFC-5056|https://tools.ietf.org/html/rfc5056#section-2.1] in section 2.1 states: > {noformat} > * If the authentication protocol used by the application supports > channel binding, the application SHOULD use it. > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9066) URLBindingTestCase fails with security manager

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-9066?page=com.atlassian.jira.plugin.... ] Yeray Borges reassigned WFLY-9066: ---------------------------------- Assignee: Yeray Borges > URLBindingTestCase fails with security manager > ---------------------------------------------- > > Key: WFLY-9066 > URL: https://issues.jboss.org/browse/WFLY-9066 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 11.0.0.Beta1 > Reporter: Ondrej Kotek > Assignee: Yeray Borges > Labels: security-manager > > {{URLBindingTestCase}} fails with security manager because of missing permissions ({{RemotingPermission("createEndpoint")}} and {{RemotingPermission("connect")}}) and dependency {{org.jboss.remoting}}. After adding the permissions and dependency, there is another missing permission: > {noformat} > ERROR [org.xnio.listener] (XNIO-1 I/O-1) XNIO001007: A channel event listener threw an exception: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/okotek/git/wildfly/dist/target/wildfly-11.0.0.Beta1-SNAPSHOT/modules/system/layers/base/org/wildfly/security/elytron-private/main/wildfly-elytron-1.1.0.CR2.jar" "read")" in code source "(vfs:/content/URLBindingTestCaseBean.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.URLBindingTestCaseBean.jar" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350) > at sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:137) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:81) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150) > at java.net.URL.openStream(URL.java:1045) > at java.util.ServiceLoader.parse(ServiceLoader.java:304) > at java.util.ServiceLoader.access$200(ServiceLoader.java:185) > at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357) > at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323) > at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396) > at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395) > at java.security.AccessController.doPrivileged(Native Method) > at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398) > at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) > at org.wildfly.security.util.ServiceLoaderSupplier.get(ServiceLoaderSupplier.java:55) > at org.wildfly.security.util.ServiceLoaderSupplier.get(ServiceLoaderSupplier.java:35) > at org.wildfly.security.util.ProviderUtil$1.get(ProviderUtil.java:139) > at org.wildfly.security.util.ProviderUtil$1.get(ProviderUtil.java:127) > at org.wildfly.security.sasl.util.SecurityProviderSaslClientFactory.createSaslClient(SecurityProviderSaslClientFactory.java:84) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) > at org.wildfly.security.sasl.util.ProtocolSaslClientFactory.createSaslClient(ProtocolSaslClientFactory.java:50) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) > at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) > at org.wildfly.security.sasl.util.PropertiesSaslClientFactory.createSaslClient(PropertiesSaslClientFactory.java:54) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) > at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50) > at org.wildfly.security.sasl.util.FilterMechanismSaslClientFactory.createSaslClient(FilterMechanismSaslClientFactory.java:102) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) > at org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory.createSaslClient(LocalPrincipalSaslClientFactory.java:74) > at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.lambda$createSaslClient$0(PrivilegedSaslClientFactory.java:64) > at java.security.AccessController.doPrivileged(Native Method) > at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.createSaslClient(PrivilegedSaslClientFactory.java:64) > at org.wildfly.security.auth.client.AuthenticationConfiguration.createSaslClient(AuthenticationConfiguration.java:1239) > at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.createSaslClient(AuthenticationContextConfigurationClient.java:347) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:418) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:571) > {noformat} > which seems to be related to REM3-258. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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 2017