June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13521) Upgrade Infinispan to 11.0.0.Final

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13521?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13521: -------------------------------- Summary: Upgrade Infinispan to 11.0.0.Final (was: Upgrade Infinispan to 11.0.x) > Upgrade Infinispan to 11.0.0.Final > ---------------------------------- > > Key: WFLY-13521 > URL: https://issues.redhat.com/browse/WFLY-13521 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 20.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > https://issues.redhat.com/projects/ISPN/versions/12342851 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5437) Unable to deploy project to kie server

by Anna Dupliak (Jira)

Anna Dupliak created DROOLS-5437: ------------------------------------ Summary: Unable to deploy project to kie server Key: DROOLS-5437 URL: https://issues.redhat.com/browse/DROOLS-5437 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Affects Versions: 7.39.0.Final Reporter: Anna Dupliak Assignee: Daniele Zonca Attachments: c.d is undefined 2.scesim, c.d is undefined.scesim, image-2020-06-16-21-39-06-147.png, undefinedType.webm Cannot deploy any project to kie-server Kie server fails deploying project with message [^c.d is undefined.scesim] [^c.d is undefined 2.scesim] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1179) Migrate the Mirror Catalog Jobs from Operator Source to Catalog Source

by Guilherme Baufaker Rêgo (Jira)

Guilherme Baufaker Rêgo created SWSQE-1179: ---------------------------------------------- Summary: Migrate the Mirror Catalog Jobs from Operator Source to Catalog Source Key: SWSQE-1179 URL: https://issues.redhat.com/browse/SWSQE-1179 Project: Kiali QE Issue Type: QE Task Reporter: Guilherme Baufaker Rêgo The job is still using the old operator-source. We should migrate to the new catalog-sources. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1178) es_sm_only is not a valid option for installing ossm on disconnected.

by Guilherme Baufaker Rêgo (Jira)

Guilherme Baufaker Rêgo created SWSQE-1178: ---------------------------------------------- Summary: es_sm_only is not a valid option for installing ossm on disconnected. Key: SWSQE-1178 URL: https://issues.redhat.com/browse/SWSQE-1178 Project: Kiali QE Issue Type: Bug Reporter: Guilherme Baufaker Rêgo Assignee: Filip Brychta Attachments: Captura de Tela 2020-06-16 às 16.11.17.png, Captura de Tela 2020-06-16 às 16.19.27.png, Captura de Tela 2020-06-16 às 16.19.40.png Using es_sm_only is not an option for installing service mesh because other images are not present. eg: prometheus. pictures attached -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1998) IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available when configuring BC FIPS on JDK 11

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1998?page=com.atlassian.jira.plugin.... ] Farah Juma edited comment on ELY-1998 at 6/16/20 2:07 PM: ---------------------------------------------------------- [~dvilkola] Not sure if this is the problem or not but one thing to try is updating the {{BouncyCastleJsseProvider}} configuration in the {{java.security}} file to specify {{BCFIPS}} as follows: {{security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider:BCFIPS}} Then try adding the following line to the {{java.security}} file that references the BCFIPS provider: {{securerandom.strongAlgorithms=DEFAULT:BCFIPS}} was (Author: fjuma): [~dvilkola] Not sure if this is the problem or not but one thing to try is updating the {{BouncyCastleJsseProvider}} configuration in the {{java.security}} file to specify {{BCFIPS}} as follows: security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider:BCFIPS Then try adding the following line to the {{java.security}} file that references the BCFIPS provider: securerandom.strongAlgorithms=DEFAULT:BCFIPS > IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available when configuring BC FIPS on JDK 11 > --------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1998 > URL: https://issues.redhat.com/browse/ELY-1998 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Diana Vilkolakova > Priority: Major > > The below steps require ELY-1982 bugfix to work. > Configure security providers in java.security file: > {code} > security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider > security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider > security.provider.3=SUN > {code} > Add the bc-fips.jar and bctls-fips-1.0.10.jar to the CLASSPATH and generate keystore in JBOSS_HOME/standalone/configuration folder: > {code} > keytool -genkeypair -alias appserver -keyalg RSA -keysize 2048 -keypass password -keystore "fips.keystore" -provider org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -providerpath $CLASSPATH -storetype BCFKS -storepass password -dname "CN=testserver,OU=TESTOU,O=TESTO,L=TESTL,ST=TESTCZ,C=TESTCZ" -validity 730 -v > {code} > Try to configure `server-ssl-context`: > {code} > module add --name=org.bouncycastle.fips --resources=/path/to/bc-fips-1.0.2.jar:/path/to/bctls-fips-1.0.10.jar > /subsystem=elytron/provider-loader=bc:add(module=org.bouncycastle.fips) > /subsystem=elytron/key-store=fipsKS:add(path=fips.keystore, relative-to=jboss.server.config.dir, credential-reference={clear-text=password}, type="BCFKS", providers=bc) > /subsystem=elytron/key-manager=fipsKM:add(key-store=fipsKS, algorithm="X509", credential-reference={clear-text=password}, providers=bc) > /subsystem=elytron/server-ssl-context=fipsSSC:add(key-manager=fipsKM, protocols=["TLSv1.2"], providers=bc) > {code} > The last command results in: > {code} > { > "outcome" => "failed", > "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.fipsSSC" => "Failed to start service > Caused by: java.lang.IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available > Caused by: java.security.NoSuchAlgorithmException: DEFAULT SecureRandom not available"}}, > "rolled-back" => true > } > {code} > The exception is happening [on this line|https://github.com/Skyllarr/wildfly-elytron/blob/ELY-1982/ssl/src/ma...] . This exception can be avoided by either using *new SecureRandom()* instead of null during initialization of sslContext, or by configuring securerandom with using *CryptoServicesRegistrar.setSecureRandom(new SecureRandom());* in code beforehand (this would require bc dependency). > I tried to configure secure random statically by setting *securerandom.strongAlgorithms=DEFAULT:BCFIPS* in java.security or by trying to pass secure random as parameter to constructor with > {code} > security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider "C:DEFRND[SHA512];ENABLE{ALL};" > {code} > but neither had any effect. I did not find how to configure this statically for Java 11 in BC documentation. > We could pass new instance of SecureRandom when initializing sslContext (if bouncycastle is used), or set secureRandom beforehand, or catch this exception and then use `new SecureRandom()`. But should we force the users to use SecureRandom set in the code by us? If users want to use Bouncycastle they should configure the secure random themselves since it is needed by the provider? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1998) IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available when configuring BC FIPS on JDK 11

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1998?page=com.atlassian.jira.plugin.... ] Farah Juma commented on ELY-1998: --------------------------------- [~dvilkola] Not sure if this is the problem or not but one thing to try is updating the {{BouncyCastleJsseProvider}} configuration in the {{java.security}} file to specify {{BCFIPS}} as follows: security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider:BCFIPS Then try adding the following line to the {{java.security}} file that references the BCFIPS provider: securerandom.strongAlgorithms=DEFAULT:BCFIPS > IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available when configuring BC FIPS on JDK 11 > --------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1998 > URL: https://issues.redhat.com/browse/ELY-1998 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Diana Vilkolakova > Priority: Major > > The below steps require ELY-1982 bugfix to work. > Configure security providers in java.security file: > {code} > security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider > security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider > security.provider.3=SUN > {code} > Add the bc-fips.jar and bctls-fips-1.0.10.jar to the CLASSPATH and generate keystore in JBOSS_HOME/standalone/configuration folder: > {code} > keytool -genkeypair -alias appserver -keyalg RSA -keysize 2048 -keypass password -keystore "fips.keystore" -provider org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -providerpath $CLASSPATH -storetype BCFKS -storepass password -dname "CN=testserver,OU=TESTOU,O=TESTO,L=TESTL,ST=TESTCZ,C=TESTCZ" -validity 730 -v > {code} > Try to configure `server-ssl-context`: > {code} > module add --name=org.bouncycastle.fips --resources=/path/to/bc-fips-1.0.2.jar:/path/to/bctls-fips-1.0.10.jar > /subsystem=elytron/provider-loader=bc:add(module=org.bouncycastle.fips) > /subsystem=elytron/key-store=fipsKS:add(path=fips.keystore, relative-to=jboss.server.config.dir, credential-reference={clear-text=password}, type="BCFKS", providers=bc) > /subsystem=elytron/key-manager=fipsKM:add(key-store=fipsKS, algorithm="X509", credential-reference={clear-text=password}, providers=bc) > /subsystem=elytron/server-ssl-context=fipsSSC:add(key-manager=fipsKM, protocols=["TLSv1.2"], providers=bc) > {code} > The last command results in: > {code} > { > "outcome" => "failed", > "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.fipsSSC" => "Failed to start service > Caused by: java.lang.IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available > Caused by: java.security.NoSuchAlgorithmException: DEFAULT SecureRandom not available"}}, > "rolled-back" => true > } > {code} > The exception is happening [on this line|https://github.com/Skyllarr/wildfly-elytron/blob/ELY-1982/ssl/src/ma...] . This exception can be avoided by either using *new SecureRandom()* instead of null during initialization of sslContext, or by configuring securerandom with using *CryptoServicesRegistrar.setSecureRandom(new SecureRandom());* in code beforehand (this would require bc dependency). > I tried to configure secure random statically by setting *securerandom.strongAlgorithms=DEFAULT:BCFIPS* in java.security or by trying to pass secure random as parameter to constructor with > {code} > security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider "C:DEFRND[SHA512];ENABLE{ALL};" > {code} > but neither had any effect. I did not find how to configure this statically for Java 11 in BC documentation. > We could pass new instance of SecureRandom when initializing sslContext (if bouncycastle is used), or set secureRandom beforehand, or catch this exception and then use `new SecureRandom()`. But should we force the users to use SecureRandom set in the code by us? If users want to use Bouncycastle they should configure the secure random themselves since it is needed by the provider? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5004) TlsTestCase#testReloadTrustManager fails on IBM Java 8

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/WFCORE-5004?page=com.atlassian.jira.plug... ] Sonia Zaldana reassigned WFCORE-5004: ------------------------------------- Assignee: Sonia Zaldana > TlsTestCase#testReloadTrustManager fails on IBM Java 8 > ------------------------------------------------------ > > Key: WFCORE-5004 > URL: https://issues.redhat.com/browse/WFCORE-5004 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 13.0.0.Beta1 > Reporter: Ondrej Kotek > Assignee: Sonia Zaldana > Priority: Major > > TlsTestCase#testReloadTrustManager fails on IBM Java 8 at [TlsTestCase.java#L439|https://github.com/wildfly/wildfly-core/blob/master...] reporting the same DN. When I try to compare using canonical names, there is a difference. Using RFC1779 or RFC2253 names is ok. > {noformat} > Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(X500Principal.CANONICAL), ISSUER_DN.getName(X500Principal.CANONICAL)); > [ERROR] TlsTestCase.testReloadTrustManager:439 expected:<....2.840.113549.1.9.1=[#1613656c7974726f6e4077696c64666c792e6f7267],c=uk,st=elytron,cn=...> but was:<....2.840.113549.1.9.1=[elytron@wildfly.org],c=uk,st=elytron,cn=...> > {noformat} > Is it just a test issue, or can there be an impact on functionality? In case it's just a test issue, can we assert equality of names? I.e. > {noformat} > Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(), ISSUER_DN.getName()); > {noformat} > The same for [TlsTestCase.java#L465|https://github.com/wildfly/wildfly-core/blob/master...] then. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2086) Intermittent failure in OperationCancellationTestCase

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFCORE-2086?page=com.atlassian.jira.plug... ] Yeray Borges Santana commented on WFCORE-2086: ---------------------------------------------- The analysis revealed there is a bug in JBoss Thread that affects to this scenario, see https://issues.redhat.com/browse/JBTHR-88 > Intermittent failure in OperationCancellationTestCase > ----------------------------------------------------- > > Key: WFCORE-2086 > URL: https://issues.redhat.com/browse/WFCORE-2086 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 5.0.0.Beta5 > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Major > > Investigate this: > https://ci.wildfly.org/viewLog.html?buildId=36108&buildTypeId=WildFlyCore... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1982) TLS with BCJSSE Provider does not work

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1982?page=com.atlassian.jira.plugin.... ] Farah Juma reassigned ELY-1982: ------------------------------- Assignee: Diana Vilkolakova > TLS with BCJSSE Provider does not work > -------------------------------------- > > Key: ELY-1982 > URL: https://issues.redhat.com/browse/ELY-1982 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Diana Vilkolakova > Assignee: Diana Vilkolakova > Priority: Major > > Configuration of `server-ssl-context` does not seem to work with BCJSSE Provider. The steps above work for EAP 7.2, however they throw the following error in EAP 7.3: > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server-ssl-context") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server-ssl-context" => "Failed to start service > Caused by: java.lang.IllegalStateException: SSLContext has not been initialized."}} > Stacktrace: > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server-ssl-context: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server-ssl-context: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalStateException: SSLContext has not been initialized. > at org.bouncycastle.jsse.provider.ProvSSLContextSpi.getContextData(Unknown Source) > at org.bouncycastle.jsse.provider.ProvSSLContextSpi.engineGetServerSessionContext(Unknown Source) > at javax.net.ssl.SSLContext.getServerSessionContext(SSLContext.java:386) > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:340) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53) > at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:1173) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) > ... 6 more -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13591) TCP_NIO2 sockets are not registered with socket binding manager

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13591: ----------------------------------- Summary: TCP_NIO2 sockets are not registered with socket binding manager Key: WFLY-13591 URL: https://issues.redhat.com/browse/WFLY-13591 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 20.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 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 June 2020