August 2018 - jboss-jira - Jboss List Archives

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

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-4002?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4002: -------------------------------- Fix Version/s: 6.0.0.CR2 (was: 6.0.0.CR1) > 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.CR2 > > > 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, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4022) The key-store obtain-certificate operation currently fails with "Parameter 'type' may not be null"

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-4022?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4022: -------------------------------- Fix Version/s: 6.0.0.CR1 (was: 6.0.0.CR2) > The key-store obtain-certificate operation currently fails with "Parameter 'type' may not be null" > -------------------------------------------------------------------------------------------------- > > Key: WFCORE-4022 > URL: https://issues.jboss.org/browse/WFCORE-4022 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: 6.0.0.CR1 > > > Currently, executing the {{key-store}} {{obtain-certificate}} operation results in: > {code} > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "Parameter 'type' may not be null", > "response-headers" => {"process-state" => "reload-required"}, > "rolled-back" => true > } > {code} > This is due to a recent Let's Encrypt change where a new challenge type was introduced but not officially added to the ACME v2 protocol spec yet. The {{WildFlyAcmeClient}} only needs to be able to handle the "http-01" challenge type but should be able to handle being presented with many challenge options. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4000) Domain tests fail on JDK11 because of missing java.se module

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-4000?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4000: -------------------------------- Fix Version/s: 6.0.0.CR2 (was: 6.0.0.CR1) > Domain tests fail on JDK11 because of missing java.se module > ------------------------------------------------------------ > > Key: WFCORE-4000 > URL: https://issues.jboss.org/browse/WFCORE-4000 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 6.0.0.Alpha5 > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 6.0.0.CR2 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3971) Referral mode should be an enumeration

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3971?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-3971: -------------------------------- Fix Version/s: 6.0.0.CR2 (was: 6.0.0.CR1) > Referral mode should be an enumeration > -------------------------------------- > > Key: WFCORE-3971 > URL: https://issues.jboss.org/browse/WFCORE-3971 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Philippe Marschall > Assignee: Darran Lofthouse > Fix For: 6.0.0.CR2 > > > The "referral-mode" attribute of the "dir-context" element only allows the values "ignore", "follow" and "throw". As a consequence it should be an enumeration of these values. > While fixing the issue I found out that model serialization would generate ALL-CAPS values. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4022) The key-store obtain-certificate operation currently fails with "Parameter 'type' may not be null"

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-4022?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4022: -------------------------------- Fix Version/s: 6.0.0.CR2 (was: 6.0.0.CR1) > The key-store obtain-certificate operation currently fails with "Parameter 'type' may not be null" > -------------------------------------------------------------------------------------------------- > > Key: WFCORE-4022 > URL: https://issues.jboss.org/browse/WFCORE-4022 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: 6.0.0.CR2 > > > Currently, executing the {{key-store}} {{obtain-certificate}} operation results in: > {code} > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "Parameter 'type' may not be null", > "response-headers" => {"process-state" => "reload-required"}, > "rolled-back" => true > } > {code} > This is due to a recent Let's Encrypt change where a new challenge type was introduced but not officially added to the ACME v2 protocol spec yet. The {{WildFlyAcmeClient}} only needs to be able to handle the "http-01" challenge type but should be able to handle being presented with many challenge options. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3386) Add configuration required to support JASPI to the Elytron subsystem and general JASPI integration.

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3386?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-3386: -------------------------------- Fix Version/s: 6.0.0.CR2 (was: 6.0.0.CR1) > Add configuration required to support JASPI to the Elytron subsystem and general JASPI integration. > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-3386 > URL: https://issues.jboss.org/browse/WFCORE-3386 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 6.0.0.CR2 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3952) Unable to run -DallTests -Delytron builds

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3952?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-3952: -------------------------------- Fix Version/s: 6.0.0.CR2 (was: 6.0.0.CR1) > Unable to run -DallTests -Delytron builds > ----------------------------------------- > > Key: WFCORE-3952 > URL: https://issues.jboss.org/browse/WFCORE-3952 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 6.0.0.CR2 > > > Attempting to use -DallTests -Delytron results in the following error: - > {noformat} > [ERROR] } > [ERROR] Cannot start embedded Host Controller: WFLYEMB0022: Cannot invoke 'start' on embedded process: WFLYHC0097: Domain base directory does not exist: /home/darranl/src/wildfly13/wildfly-core/testsuite/standalone/target/wildfly-core/domain > {noformat} > I believe this is actually caused by WFCORE-3769 which provisions a standalone server only. > We don't currently run -Delytron jobs for WildFly Core but this bug causes problems with experimental builds where we may want to use -Delytron. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4038) Upgrade WildFly Elytron to 1.5.5.Final

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-4038?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4038: -------------------------------- Fix Version/s: 6.0.0.CR2 (was: 6.0.0.CR1) > Upgrade WildFly Elytron to 1.5.5.Final > -------------------------------------- > > Key: WFCORE-4038 > URL: https://issues.jboss.org/browse/WFCORE-4038 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 6.0.0.CR2 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-65) [Artemis 2.x upgrade] Artemis RA connections disconnected after failover

by Clebert Suconic (JIRA)

[ https://issues.jboss.org/browse/WFWIP-65?page=com.atlassian.jira.plugin.s... ] Clebert Suconic commented on WFWIP-65: -------------------------------------- Any update ? > [Artemis 2.x upgrade] Artemis RA connections disconnected after failover > ------------------------------------------------------------------------- > > Key: WFWIP-65 > URL: https://issues.jboss.org/browse/WFWIP-65 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Clebert Suconic > Priority: Blocker > Labels: feature-branch-blocker > Attachments: DedicatedFailoverTestCaseWithMdb.testShutdownWithFailback.zip > > > There is regression againt Artemis 1.5.5.0012 in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover) > Test scenario: > * There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology. > * InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server. > * When all messages are sent, deploy message driven bean on Node 3. > * MDB sends messages form InQueue to OutQueue. > * Shutdown live server. Wait for backup server to alive, then start live server again and stop backup. > * Receive messages from OutQueue from live server. > Results: > After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection. > Attaching reproduce and logs. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-65) [Artemis 2.x upgrade] Artemis RA connections disconnected after failover

by Clebert Suconic (JIRA)

[ https://issues.jboss.org/browse/WFWIP-65?page=com.atlassian.jira.plugin.s... ] Clebert Suconic commented on WFWIP-65: -------------------------------------- I mean. Any ideas on where this is happening ? > [Artemis 2.x upgrade] Artemis RA connections disconnected after failover > ------------------------------------------------------------------------- > > Key: WFWIP-65 > URL: https://issues.jboss.org/browse/WFWIP-65 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Clebert Suconic > Priority: Blocker > Labels: feature-branch-blocker > Attachments: DedicatedFailoverTestCaseWithMdb.testShutdownWithFailback.zip > > > There is regression againt Artemis 1.5.5.0012 in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover) > Test scenario: > * There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology. > * InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server. > * When all messages are sent, deploy message driven bean on Node 3. > * MDB sends messages form InQueue to OutQueue. > * Shutdown live server. Wait for backup server to alive, then start live server again and stop backup. > * Receive messages from OutQueue from live server. > Results: > After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection. > Attaching reproduce and logs. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 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