September 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1680) IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1680?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1680: ---------------------------------- Fix Version/s: 1.7.0.CR2 > IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary > ------------------------------------------------------------- > > Key: ELY-1680 > URL: https://issues.jboss.org/browse/ELY-1680 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Affects Versions: 1.6.1.Final > Reporter: Martin Choma > Fix For: 1.7.0.CR2 > > > {code} > [ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE! > org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...> > at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136) > at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218) > {code} > If I switch order of certificates in chain, then test passes. > {code} > diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java > index d8095867a..cda635beb 100644 > --- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java > +++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java > @@ -133,8 +133,8 @@ public class KeyStoreSuiteChild { > Certificate[] chain = keyStore.getCertificateChain("firefly_binary"); > Assert.assertNotNull(chain); > Assert.assertEquals(2, chain.length); > - Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString()); > - Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString()); > + Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString()); > + Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString()); > } > {code} > -For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.- > It takes long (5min) for debugger to attach to code. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1679) (7.1.z) SASL property com.sun.security.sasl.digest.utf8 does not behave as default when its default value is explicitely configured

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1679?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1679: ---------------------------------- Fix Version/s: 1.1.12.CR1 > (7.1.z) SASL property com.sun.security.sasl.digest.utf8 does not behave as default when its default value is explicitely configured > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1679 > URL: https://issues.jboss.org/browse/ELY-1679 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.11.Final > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > Fix For: 1.1.12.CR1 > > > SASL property *com.sun.security.sasl.digest.utf8* does not behave as default when its default value is explicitely configured. > When we ommit this explicit property setting then everything is fine. > This property is described here [1] and *true* is default value. Property is defined in wildfly-core project org.wildfly.security.sasl.WildFlySasl.USE_UTF8. > Here is how to set it [2]. > Please check Steps to Reproduce, there is how to update test. > [1] https://doc-stage.usersys.redhat.com/documentation/en-us/red_hat_jboss_en... > [2] https://doc-stage.usersys.redhat.com/documentation/en-us/red_hat_jboss_en... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-203) LogManager stops any logging output after changing "encoding" attribute to file-handler

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-203?page=com.atlassian.jira.plugin... ] David Lloyd moved WFLY-11081 to LOGMGR-203: ------------------------------------------- Project: JBoss Log Manager (was: WildFly) Key: LOGMGR-203 (was: WFLY-11081) Component/s: core (was: Logging) Affects Version/s: (was: 14.0.0.Final) > LogManager stops any logging output after changing "encoding" attribute to file-handler > --------------------------------------------------------------------------------------- > > Key: LOGMGR-203 > URL: https://issues.jboss.org/browse/LOGMGR-203 > Project: JBoss Log Manager > Issue Type: Bug > Components: core > Reporter: Masafumi Miura > Assignee: James Perkins > > When setting "encoding" attribute on the file handler (file-handler, periodic-rotating-file-handler, size-rotating-file-handler, and periodic-size-rotating-file-handler) in CLI, LogManager throw the following error message in the console log and stops any logging output to the file-handler. > Note that the stack trace below "org.jboss.logmanager.Logger.logRaw(Logger.java:850)" can differ. It looks like this error just happens on the first logging output after the configuration change. > Even after executing ":reload" the instance via CLI, no log message are output to the file-handler. The instance needs to restart to output the file-handler. > {code} > LogManager error of type FLUSH_FAILURE: Error on flush > java.io.IOException: Stream Closed > at java.io.FileOutputStream.writeBytes(Native Method) > at java.io.FileOutputStream.write(FileOutputStream.java:326) > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110) > at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297) > at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) > at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) > at java.io.BufferedWriter.flush(BufferedWriter.java:254) > at org.jboss.logmanager.handlers.WriterHandler.safeFlush(WriterHandler.java:170) > at org.jboss.logmanager.handlers.WriterHandler.flush(WriterHandler.java:139) > at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105) > at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:67) > at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:77) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:333) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) > at org.jboss.logmanager.Logger.logRaw(Logger.java:850) > at org.jboss.logmanager.Logger.log(Logger.java:802) > at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53) > at org.jboss.logging.Logger.logf(Logger.java:2398) > at org.jboss.as.mail.extension.MailLogger_$logger.unboundMailSession(MailLogger_$logger.java:42) > at org.jboss.as.mail.extension.MailSessionAdd$1.handleEvent(MailSessionAdd.java:150) > at org.jboss.msc.service.ServiceControllerImpl$LifecycleListenerTask.execute(ServiceControllerImpl.java:1857) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364) > at java.lang.Thread.run(Thread.java:748) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1681) Include the thrown exception in the trace logging in SSLUtils#createSslContextFactory()

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1681?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1681: ---------------------------------- Fix Version/s: 1.7.0.CR2 > Include the thrown exception in the trace logging in SSLUtils#createSslContextFactory() > --------------------------------------------------------------------------------------- > > Key: ELY-1681 > URL: https://issues.jboss.org/browse/ELY-1681 > Project: WildFly Elytron > Issue Type: Task > Components: SSL > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: 1.7.0.CR2 > > > Include the thrown exception in the trace logging in {{SSLUtils#createSslContextFactory()}} to try to reveal more information for ELY-1663. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11073) Support hex encoding in jdbc-realm for elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-11073?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFLY-11073: ------------------------------------ Fix Version/s: 15.0.0.Alpha1 > Support hex encoding in jdbc-realm for elytron > ---------------------------------------------- > > Key: WFLY-11073 > URL: https://issues.jboss.org/browse/WFLY-11073 > Project: WildFly > Issue Type: Feature Request > Components: Documentation, Security > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: elytron > Fix For: 15.0.0.Alpha1 > > > Old database login-module can be configured passing the attribute {{hashEncoding}}, for example: > {code:xml} > <login-module code="Database" flag="required"> > <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/> > <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/> > <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/> > <module-option name="hashAlgorithm" value="SHA-1"/> > <module-option name="hashEncoding" value="hex"/> > <module-option name="hashCharset" value="UTF-8"/> > </login-module> > {code} > Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron. > Think also about the charset attribute. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1682?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1682: ---------------------------------- Fix Version/s: 1.7.0.CR2 > Fallback to another SASL client mechanism when SASL client initialisation fails > ------------------------------------------------------------------------------- > > Key: ELY-1682 > URL: https://issues.jboss.org/browse/ELY-1682 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.7.0.CR1 > Reporter: Martin Choma > Fix For: 1.7.0.CR2 > > Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt > > > {code:title=HipChat conversation} > Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential. > But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok. > I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for? > Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected > Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case). > In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved. > Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting > though for that one as that is where that loop happens but start with an ELY issue > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1683) Add more trace logging in SSLUtils#createSslContextFactory to indicate which protocols and providers are attempted

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1683?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1683: ---------------------------------- Fix Version/s: 1.7.0.CR2 > Add more trace logging in SSLUtils#createSslContextFactory to indicate which protocols and providers are attempted > ------------------------------------------------------------------------------------------------------------------ > > Key: ELY-1683 > URL: https://issues.jboss.org/browse/ELY-1683 > Project: WildFly Elytron > Issue Type: Task > Components: SSL > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: 1.7.0.CR2 > > > Add trace logging to indicate which protocol and provider pairs are attempted when calling {{SSLContext.getInstance()}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-398) The jboss-web_7_1.xsd and 7.2.xsd file cause validation errors in Eclipse

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/JBMETA-398?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet resolved JBMETA-398. -------------------------------------- Resolution: Done Done, update to jboss-web_7_3.xsd > The jboss-web_7_1.xsd and 7.2.xsd file cause validation errors in Eclipse > ------------------------------------------------------------------------- > > Key: JBMETA-398 > URL: https://issues.jboss.org/browse/JBMETA-398 > Project: JBoss Metadata > Issue Type: Bug > Components: web > Affects Versions: 7.2.0.Final > Reporter: Radovan Netuka > Assignee: Radovan Netuka > Fix For: 12.0.0.Final > > > The jboss-web_7_2.xsd file cause validation errors in eclipse. > The following error from line 261: > src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When <simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is specified, a simple type. 'boolean' satisfies none of these conditions > This also happens in jboss-web_7_1.xsd -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-398) The jboss-web_7_1.xsd and 7.2.xsd file cause validation errors in Eclipse

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/JBMETA-398?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet updated JBMETA-398: ------------------------------------- Fix Version/s: 12.0.0.Final > The jboss-web_7_1.xsd and 7.2.xsd file cause validation errors in Eclipse > ------------------------------------------------------------------------- > > Key: JBMETA-398 > URL: https://issues.jboss.org/browse/JBMETA-398 > Project: JBoss Metadata > Issue Type: Bug > Components: web > Affects Versions: 7.2.0.Final > Reporter: Radovan Netuka > Assignee: Radovan Netuka > Fix For: 12.0.0.Final > > > The jboss-web_7_2.xsd file cause validation errors in eclipse. > The following error from line 261: > src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When <simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is specified, a simple type. 'boolean' satisfies none of these conditions > This also happens in jboss-web_7_1.xsd -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-406) Deprecate ReplicationConfig and remove from next schema version

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/JBMETA-406?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet updated JBMETA-406: ------------------------------------- Fix Version/s: (was: 12.0.0.Final) > Deprecate ReplicationConfig and remove from next schema version > --------------------------------------------------------------- > > Key: JBMETA-406 > URL: https://issues.jboss.org/browse/JBMETA-406 > Project: JBoss Metadata > Issue Type: Task > Components: web > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > This configuration is planning to grow in complexity and is moving into a WildFly subsystem. > See: https://issues.jboss.org/browse/WFLY-5550 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 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 September 2018