August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1635) Release WildFly Elytron 1.5.3.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1635: ------------------------------------- Summary: Release WildFly Elytron 1.5.3.Final Key: ELY-1635 URL: https://issues.jboss.org/browse/ELY-1635 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.5.3.CR1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1630) Ignore any blank lines in between the certificates in the certificate chain returned by an ACME server to avoid parsing issues on IBM JDK

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-1630?page=com.atlassian.jira.plugin.s... ] Farah Juma resolved ELY-1630. ----------------------------- Fix Version/s: 1.5.3.CR1 Resolution: Done > Ignore any blank lines in between the certificates in the certificate chain returned by an ACME server to avoid parsing issues on IBM JDK > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1630 > URL: https://issues.jboss.org/browse/ELY-1630 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: 1.5.3.CR1 > > > Currently, {{AcmeClientSpiTest#testObtainCertificateChainWithKeySize}} and {{AcmeClientSpiTest#testObtainCertificateChainWithECPublicKey}} fail when run with IBM JDK with the following error: > {code} > org.wildfly.security.x500.cert.acme.AcmeException: ELY10049: Unable to download certificate chain from ACME server > at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:988) > at org.wildfly.security.x500.cert.acme.AcmeClientSpi.obtainCertificateChain(AcmeClientSpi.java:519) > at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.obtainCertificateChain(AcmeClientSpiTest.java:284) > at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.testObtainCertificateChainWithKeySize(AcmeClientSpiTest.java:260) > Caused by: java.security.cert.CertificateException: Unable to initialize, java.io.IOException: insufficient data > at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:268) > at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:448) > at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:984) > ... 3 more > {code} > The underlying issue is that the PEM certificate chain returned by the ACME server has a blank line in between the two certificates in the chain. This causes parsing issues on IBM JDK when {{CertificateFactory.generateCertificates()}} is called. To fix this, we can just ignore any blank lines in the chain. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-102) SNI - hostname notation for sni-mapping element does not conform generic rules

by Jan Stourac (JIRA)

Jan Stourac created WFWIP-102: --------------------------------- Summary: SNI - hostname notation for sni-mapping element does not conform generic rules Key: WFWIP-102 URL: https://issues.jboss.org/browse/WFWIP-102 Project: WildFly WIP Issue Type: Bug Environment: Wildfly build with undertow and wildfly-core modules build from following sources: * https://github.com/stuartwdouglas/undertow/tree/sni * https://github.com/stuartwdouglas/wildfly-core/tree/sni Reporter: Jan Stourac Assignee: Stuart Douglas Way of configuration of {{sni-mapping}} element in {{server-ssl-sni-context}} is not nice from UX and also does not conform the way it is generally used. With current implementation administrator has to use following notation: {code} .*\.example\.com {code} This is standard reg-exp notation and is not for easy reading. I think following notation is much better and also is commonly used for this cases: {code} *.example.com {code} In other words - simple asterisk is used to match any subdomain and dot in our case does not stand for 'any single character'. Note that is the way it was described in [analysis document|https://github.com/wildfly/wildfly-proposals/pull/67/files#diff-...]. Truth is that with this change we loose some flexibility, e.g. administrator won't be able to configure following: {code} www\.exa.ple\.com {code} But I doubt this is a common use case. WDYT? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4015) Ensure the certificate-authority-account create-account operation returns an appropriate message if the account already exists

by Farah Juma (JIRA)

Farah Juma created WFCORE-4015: ---------------------------------- Summary: Ensure the certificate-authority-account create-account operation returns an appropriate message if the account already exists Key: WFCORE-4015 URL: https://issues.jboss.org/browse/WFCORE-4015 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Farah Juma Assignee: Farah Juma If an account has already been created with LetsEncrypt and the {{create-account}} operation is called again, ensure that an appropriate message is returned so the user is aware that the {{create-account}} operation won't have an effect and that {{update-account}} should be used to make any further changes to the account. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4002) Some security tests fail on closed channel exception

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-4002?page=com.atlassian.jira.plugi... ] Jan Kalina commented on WFCORE-4002: ------------------------------------ The problem is TLSv1.3, where DSA keys are forbidden - keystores used in tests needs to be regenerated for RSA. > Some security tests fail on closed channel exception > ---------------------------------------------------- > > Key: WFCORE-4002 > URL: https://issues.jboss.org/browse/WFCORE-4002 > Project: WildFly Core > Issue Type: Bug > Components: Security, Test Suite > Affects Versions: 6.0.0.Alpha5 > Reporter: Richard Opalka > Assignee: Jan Kalina > Priority: Blocker > Labels: jdk11 > Fix For: 6.0.0.Alpha6 > > > With latest JDK11 (build 11-ea+25) the following tests fail due to closed channel exception: > * domain-management/src/test/java/org/jboss/as/domain/management/security/auditlog/AuditLogHandlerBootEnabledTestCase.java > * testsuite/domain/src/test/java/org/jboss/as/test/integration/domain/HTTPSManagementInterfaceTestCase.java > * testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosNativeMgmtSaslTestCase.java > * testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/ScramPlusMgmtSaslTestCase.java > * testsuite/manualmode/src/test/java/org/wildfly/core/test/standalone/mgmt/HTTPSManagementInterfaceTestCase.java > Is there a known SSL issue in JDK11? Could somebody from our security team investigate this issue? > When these tests will start passing WFCORE test suite will be passing 100% of tests on JDK11. > Potential investigator from our security team may want to include this PR: > https://github.com/wildfly/wildfly-core/pull/3420 > to fix known JDK11 issues. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-200) SSLProtocolException: Connection reset on JDK11

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-200?page=com.atlassian.jira.plugin... ] Jan Kalina updated LOGMGR-200: ------------------------------ Priority: Major (was: Blocker) > SSLProtocolException: Connection reset on JDK11 > ----------------------------------------------- > > Key: LOGMGR-200 > URL: https://issues.jboss.org/browse/LOGMGR-200 > Project: JBoss Log Manager > Issue Type: Bug > Affects Versions: 2.1.4.Final > Reporter: Jan Kalina > Assignee: Jan Kalina > > testTlsConnection and other SSL related tests in SocketHandlerTests fails on JDK11: > {code} > LogManager error of type FLUSH_FAILURE: Error on flush > javax.net.ssl.SSLProtocolException: Connection reset > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) > at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:325) > at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:268) > at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:137) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:877) > at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:810) > at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:383) > at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:477) > at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:709) > at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:188) > at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84) > at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233) > at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312) > at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:316) > at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:153) > at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:254) > at org.jboss.logmanager.handlers.SocketHandler.safeFlush(SocketHandler.java:512) > at org.jboss.logmanager.handlers.SocketHandler.flush(SocketHandler.java:228) > at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105) > at org.jboss.logmanager.handlers.SocketHandler.doPublish(SocketHandler.java:218) > at org.jboss.logmanager.handlers.SocketHandlerTests.testTlsConnection(SocketHandlerTests.java:59) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) > at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) > at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.intellij.rt.execution.application.AppMainV2.main(AppMainV2.java:131) > Caused by: java.net.SocketException: Connection reset > at java.base/java.net.SocketInputStream.read(SocketInputStream.java:186) > at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140) > at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:464) > at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > ... 46 more > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertNotNull(Assert.java:712) > at org.junit.Assert.assertNotNull(Assert.java:722) > at org.jboss.logmanager.handlers.SocketHandlerTests.testTlsConnection(SocketHandlerTests.java:61) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) > at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) > at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.intellij.rt.execution.application.AppMainV2.main(AppMainV2.java:131) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3991) read-config-as-features management operation

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3991?page=com.atlassian.jira.plugi... ] Alexey Loubyansky updated WFCORE-3991: -------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3438 (was: https://github.com/wildfly/wildfly-core/pull/3430) > read-config-as-features management operation > -------------------------------------------- > > Key: WFCORE-3991 > URL: https://issues.jboss.org/browse/WFCORE-3991 > Project: WildFly Core > Issue Type: Feature Request > Components: Management, Server > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 6.0.0.Alpha6 > > > Currently we have read-feature-description management operation which returns descriptions of available provisioning features, which is the basis for Galleon feature spec generation. > I would like to add another operation that will describe the current state of the management model in terms of provisioning features (for both standalone and domain modes). The result of this operation will be used to identify user configuration changes since the last provisioned state, which will have to be done for basically any provisioning operation (such as applying patches, installing updates, etc). > I would like to have it in EAP 7.2 even if Galleon patching is postponed to a 7.3. This feature will still allow us to upgrade from 7.2 to 7.3. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2823) FEEL Parser: `not` breaks with `list contains`

by Edoardo Vacchi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2823?page=com.atlassian.jira.plugi... ] Edoardo Vacchi edited comment on DROOLS-2823 at 8/10/18 9:52 AM: ----------------------------------------------------------------- work on this issue has been done in this PR https://github.com/kiegroup/drools/pull/2014 ultimately closed that PR. It is advised to perform a bit of refactoring on the parser in order to fix this properly was (Author: evacchi): work on this issue has been done in this PR https://github.com/kiegroup/drools/pull/2014 ultimately closed this, as it required more work. It is advised to perform a bit of refactoring on the parser > FEEL Parser: `not` breaks with `list contains` > ----------------------------------------------- > > Key: DROOLS-2823 > URL: https://issues.jboss.org/browse/DROOLS-2823 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > > *list contains([1,2,3,4,5,6], 3)* returns true > *not(list contains([1,2,3,4,5,6], 3))* returns “list contains([1,2,3,4,5,6], 3)”, it should return false > Most likely related to an issue with the parse tree branches -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-88) [Artemis 2.x upgrade] Server shutdown hangs with active MDB

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFWIP-88?page=com.atlassian.jira.plugin.s... ] Miroslav Novak closed WFWIP-88. ------------------------------- Resolution: Done > [Artemis 2.x upgrade] Server shutdown hangs with active MDB > ----------------------------------------------------------- > > Key: WFWIP-88 > URL: https://issues.jboss.org/browse/WFWIP-88 > Project: WildFly WIP > Issue Type: Bug > Components: JMS > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Priority: Blocker > Attachments: logs.zip > > > There is regression in scenario where server with MDB which is connected throught remote JCA to another server cannot be cleanly shutdown (or it takes very long time) when remote server is killed. This is similar issue as JBEAP-9123. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2823) FEEL Parser: `not` breaks with `list contains`

by Edoardo Vacchi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2823?page=com.atlassian.jira.plugi... ] Edoardo Vacchi commented on DROOLS-2823: ---------------------------------------- work on this issue has been done in this PR https://github.com/kiegroup/drools/pull/2014 ultimately closed this, as it required more work. It is advised to perform a bit of refactoring on the parser > FEEL Parser: `not` breaks with `list contains` > ----------------------------------------------- > > Key: DROOLS-2823 > URL: https://issues.jboss.org/browse/DROOLS-2823 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > > *list contains([1,2,3,4,5,6], 3)* returns true > *not(list contains([1,2,3,4,5,6], 3))* returns “list contains([1,2,3,4,5,6], 3)”, it should return false > Most likely related to an issue with the parse tree branches -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 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 August 2018