June 2020 - jboss-jira - Jboss List Archives

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

by Diana Vilkolakova (Jira)

Diana Vilkolakova created ELY-1998: -------------------------------------- Summary: 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 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)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2484) SSL_KEY_EXCHANGE: Add support for WildFly OpenSSL

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2484?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2484: --------------------------- Fix Version/s: 5.0.0.Final Can you provide a PR? Is this necessary in 4.x as well? > SSL_KEY_EXCHANGE: Add support for WildFly OpenSSL > ------------------------------------------------- > > Key: JGRP-2484 > URL: https://issues.redhat.com/browse/JGRP-2484 > Project: JGroups > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: Bela Ban > Priority: Major > Fix For: 5.0.0.Final > > > WildFly OpenSSL provides a high-performance implementation of SSLContext. > While SSL_KEY_EXCHANGE supports passing custom SSLContext instances through the programmatic API, this is not possible through the declarative API. > It should be possible to detect the presence of WildFly OpenSSL on the classpath and use it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1177) Disconnected Cluster 4.4 Installation failed on UPI

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1177?page=com.atlassian.jira.plugi... ] Filip Brychta closed SWSQE-1177. -------------------------------- Resolution: Done **The failure was caused by "No package matching 'podman' found available, installed or updated" which happened because of "The server encountered an internal error or misconfiguration and was unable to.." when trying to registry the VM via subscription manager. There was some issue with 'subscription.rhsm.stage.redhat.com:443' yesterday which is not under our control. It's working fine now again. OCP 4.4 disconnected was provisioned correctly. > Disconnected Cluster 4.4 Installation failed on UPI > --------------------------------------------------- > > Key: SWSQE-1177 > URL: https://issues.redhat.com/browse/SWSQE-1177 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Filip Brychta > Priority: Blocker > > > Jenkins Job Log: > > [https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/install-ocp-upi...] > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5257) DMN integration with new PMML

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5257?page=com.atlassian.jira.plug... ] Gabriele Cardosi closed DROOLS-5257. ------------------------------------ Resolution: Duplicate Implemented inside DROOLS-5372 > DMN integration with new PMML > ----------------------------- > > Key: DROOLS-5257 > URL: https://issues.redhat.com/browse/DROOLS-5257 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > General needs: > Implement `AbstractPMMLInvocationEvaluator` using new KiePMML evaluator. > See `DMNKiePMMLInvocationEvaluator` and replace PMML4ExecutionHelper. > Modify also `PMMLInvocationEvaluatorFactory.newInstance` > Look before at how abstract/coexistence with legacy model has been implemented (https://issues.redhat.com/browse/DROOLS-5372) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2484) SSL_KEY_EXCHANGE: Add support for WildFly OpenSSL

by Tristan Tarrant (Jira)

Tristan Tarrant created JGRP-2484: ------------------------------------- Summary: SSL_KEY_EXCHANGE: Add support for WildFly OpenSSL Key: JGRP-2484 URL: https://issues.redhat.com/browse/JGRP-2484 Project: JGroups Issue Type: Enhancement Reporter: Tristan Tarrant Assignee: Bela Ban WildFly OpenSSL provides a high-performance implementation of SSLContext. While SSL_KEY_EXCHANGE supports passing custom SSLContext instances through the programmatic API, this is not possible through the declarative API. It should be possible to detect the presence of WildFly OpenSSL on the classpath and use it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5434) Incorrect warning about file declaring wrong package

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5434?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5434: -------------------------------- Sprint: 2020 Week 25-27 (from Jun 15) > Incorrect warning about file declaring wrong package > ---------------------------------------------------- > > Key: DROOLS-5434 > URL: https://issues.redhat.com/browse/DROOLS-5434 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Magnus Larsson > Assignee: Mario Fusco > Priority: Major > > I am running Drools in a Spring-Boot jar and get the following warning statement _File 'BOOT-INF/classes/com/example/test/TEST.drl' is in folder 'BOOT-INF/classes/com/example/test' but declares package 'com.example.test'. It is advised to have a correspondance between package and folder names_. The package name in the drl file is correct, the problem is just that _BOOT-INF.classes._ isn't considered when evaluating if printing the warning or not. > I have tracked it down to *KieBuilderImpl.java*, method *isFileInKieBase*. The last 2 lines in that method calls: > {code:java} > // Does not care about SUPPORTED_RESOURCES_ROOTS, thus prints the warning > String pkgNameForFile = packageNameForFile( fileName, folderNameForFile, !useFolders, file ); > // Does care about SUPPORTED_RESOURCES_ROOTS, so the drl file is loaded > return isPackageInKieBase( kieBase, pkgNameForFile ); > {code} > As it is implemented right now, the warning might either be a false-positive (and still get loaded), or the package is wrong (and the file is not loaded). > Voting to include the SUPPORTED_RESOURCES_ROOTS as valid prefixes when checking if the warning should be printed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5434) Incorrect warning about file declaring wrong package

by Magnus Larsson (Jira)

[ https://issues.redhat.com/browse/DROOLS-5434?page=com.atlassian.jira.plug... ] Magnus Larsson updated DROOLS-5434: ----------------------------------- Description: I am running Drools in a Spring-Boot jar and get the following warning statement _File 'BOOT-INF/classes/com/example/test/TEST.drl' is in folder 'BOOT-INF/classes/com/example/test' but declares package 'com.example.test'. It is advised to have a correspondance between package and folder names_. The package name in the drl file is correct, the problem is just that _BOOT-INF.classes._ isn't considered when evaluating if printing the warning or not. I have tracked it down to *KieBuilderImpl.java*, method *isFileInKieBase*. The last 2 lines in that method calls: {code:java} // Does not care about SUPPORTED_RESOURCES_ROOTS, thus prints the warning String pkgNameForFile = packageNameForFile( fileName, folderNameForFile, !useFolders, file ); // Does care about SUPPORTED_RESOURCES_ROOTS, so the drl file is loaded return isPackageInKieBase( kieBase, pkgNameForFile ); {code} As it is implemented right now, the warning might either be a false-positive (and still get loaded), or the package is wrong (and the file is not loaded). Voting to include the SUPPORTED_RESOURCES_ROOTS as valid prefixes when checking if the warning should be printed. was: I am running Drools in a Spring-Boot jar and get the following warning statement _File 'BOOT-INF/classes/com/example/test/TEST.drl' is in folder 'BOOT-INF/classes/com/example/test' but declares package 'com.example.test'. It is advised to have a correspondance between package and folder names_. The package name in the drl file is correct, the problem is just that _BOOT-INF.classes._ isn't considered when evaluating if printing the warning or not. I have tracked it down to KieBuilderImpl.java, method isFileInKieBase. The last 2 lines in that method calls: {code:java} // Does not care about SUPPORTED_RESOURCES_ROOTS, thus prints the warning String pkgNameForFile = packageNameForFile( fileName, folderNameForFile, !useFolders, file ); // Does care about SUPPORTED_RESOURCES_ROOTS, so the drl file is loaded return isPackageInKieBase( kieBase, pkgNameForFile ); {code} As it is implemented right now, the warning might either be a false-positive (and still get loaded), or the package is wrong (and the file is not loaded). Voting to include the SUPPORTED_RESOURCES_ROOTS as valid prefixes when checking if the warning should be printed. > Incorrect warning about file declaring wrong package > ---------------------------------------------------- > > Key: DROOLS-5434 > URL: https://issues.redhat.com/browse/DROOLS-5434 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Magnus Larsson > Assignee: Mario Fusco > Priority: Major > > I am running Drools in a Spring-Boot jar and get the following warning statement _File 'BOOT-INF/classes/com/example/test/TEST.drl' is in folder 'BOOT-INF/classes/com/example/test' but declares package 'com.example.test'. It is advised to have a correspondance between package and folder names_. The package name in the drl file is correct, the problem is just that _BOOT-INF.classes._ isn't considered when evaluating if printing the warning or not. > I have tracked it down to *KieBuilderImpl.java*, method *isFileInKieBase*. The last 2 lines in that method calls: > {code:java} > // Does not care about SUPPORTED_RESOURCES_ROOTS, thus prints the warning > String pkgNameForFile = packageNameForFile( fileName, folderNameForFile, !useFolders, file ); > // Does care about SUPPORTED_RESOURCES_ROOTS, so the drl file is loaded > return isPackageInKieBase( kieBase, pkgNameForFile ); > {code} > As it is implemented right now, the warning might either be a false-positive (and still get loaded), or the package is wrong (and the file is not loaded). > Voting to include the SUPPORTED_RESOURCES_ROOTS as valid prefixes when checking if the warning should be printed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5434) Incorrect warning about file declaring wrong package

by Magnus Larsson (Jira)

Magnus Larsson created DROOLS-5434: -------------------------------------- Summary: Incorrect warning about file declaring wrong package Key: DROOLS-5434 URL: https://issues.redhat.com/browse/DROOLS-5434 Project: Drools Issue Type: Bug Components: core engine Reporter: Magnus Larsson Assignee: Mario Fusco I am running Drools in a Spring-Boot jar and get the following warning statement _File 'BOOT-INF/classes/com/example/test/TEST.drl' is in folder 'BOOT-INF/classes/com/example/test' but declares package 'com.example.test'. It is advised to have a correspondance between package and folder names_. The package name in the drl file is correct, the problem is just that _BOOT-INF.classes._ isn't considered when evaluating if printing the warning or not. I have tracked it down to KieBuilderImpl.java, method isFileInKieBase. The last 2 lines in that method calls: {code:java} // Does not care about SUPPORTED_RESOURCES_ROOTS, thus prints the warning String pkgNameForFile = packageNameForFile( fileName, folderNameForFile, !useFolders, file ); // Does care about SUPPORTED_RESOURCES_ROOTS, so the drl file is loaded return isPackageInKieBase( kieBase, pkgNameForFile ); {code} As it is implemented right now, the warning might either be a false-positive (and still get loaded), or the package is wrong (and the file is not loaded). Voting to include the SUPPORTED_RESOURCES_ROOTS as valid prefixes when checking if the warning should be printed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5433) DMN Strongly typed generate JSON Schema

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5433: -------------------------------------- Summary: DMN Strongly typed generate JSON Schema Key: DROOLS-5433 URL: https://issues.redhat.com/browse/DROOLS-5433 Project: Drools Issue Type: Feature Request Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-278) PeriodicRotatingFileHandler may fail to rotate a file with a security permission

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-278?page=com.atlassian.jira.plugi... ] James Perkins closed LOGMGR-278. -------------------------------- Resolution: Rejected The actual issue is setting the file not rotating it which seems correct. > PeriodicRotatingFileHandler may fail to rotate a file with a security permission > -------------------------------------------------------------------------------- > > Key: LOGMGR-278 > URL: https://issues.redhat.com/browse/LOGMGR-278 > Project: JBoss Log Manager > Issue Type: Bug > Components: core > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Fix For: 2.2.0.Final, 2.1.17.Final, 2.3.0.Beta1 > > > During rotate the {{File.lastModified()}} time is used to determine if the file is ready to rotate. In situations such as a deployment on WildFly the deployment itself may fail to log a message as the security context is that of the deployment. The reason for the failure is the deployment does not have read permissions for the file. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2020