June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1189) Automate Overview actions

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1189: ------------------------------------- Summary: Automate Overview actions Key: SWSQE-1189 URL: https://issues.redhat.com/browse/SWSQE-1189 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan https://github.com/kiali/kiali-ui/pull/1830 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5014) Log files truncated when jboss.as.management.blocking.timeout error happens on startup

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-5014?page=com.atlassian.jira.plug... ] James Perkins updated WFCORE-5014: ---------------------------------- Fix Version/s: 13.0.0.Beta1 > Log files truncated when jboss.as.management.blocking.timeout error happens on startup > -------------------------------------------------------------------------------------- > > Key: WFCORE-5014 > URL: https://issues.redhat.com/browse/WFCORE-5014 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: David Boeren > Assignee: James Perkins > Priority: Blocker > Fix For: 13.0.0.Beta1 > > Attachments: sample-test-war-0.0.1-SNAPSHOT.war, standalone_example.xml > > > After receiving a jboss.as.management.blocking.timeout error on startup, all the log files are truncated to zero bytes. This behavior happens on any patch level of EAP 7.2.x and also on EAP 7.3 but does not happen on EAP 7.1.6. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5014) Log files truncated when jboss.as.management.blocking.timeout error happens on startup

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-5014?page=com.atlassian.jira.plug... ] James Perkins moved JBEAP-19727 to WFCORE-5014: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-5014 (was: JBEAP-19727) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Logging (was: Logging) Affects Version/s: (was: 7.2.0.GA) (was: 7.3.0.GA) > Log files truncated when jboss.as.management.blocking.timeout error happens on startup > -------------------------------------------------------------------------------------- > > Key: WFCORE-5014 > URL: https://issues.redhat.com/browse/WFCORE-5014 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: David Boeren > Assignee: James Perkins > Priority: Blocker > Attachments: sample-test-war-0.0.1-SNAPSHOT.war, standalone_example.xml > > > After receiving a jboss.as.management.blocking.timeout error on startup, all the log files are truncated to zero bytes. This behavior happens on any patch level of EAP 7.2.x and also on EAP 7.3 but does not happen on EAP 7.1.6. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13606) Ignored socket-level keepalive flag in OpenJDK ORB connections

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-13606: ------------------------------------- Summary: Ignored socket-level keepalive flag in OpenJDK ORB connections Key: WFLY-13606 URL: https://issues.redhat.com/browse/WFLY-13606 Project: WildFly Issue Type: Bug Components: IIOP Reporter: Tomasz Adamski Assignee: Tomasz Adamski Restored the ability to use socket-level keepalive flag in OpenJDK ORB connections after it became impossible in Wildfly 11. Wildfly version 11 brought in the following change: [{{09b79c4}}#diff-cabdeec060c4801f721b35660a6081a3R347 |https://g... starts to implicitly declare the property com.sun.CORBA.transport.ORBSocketFactoryClass to value org.wildfly.iiop.openjdk.security.NoSSLSocketFactory due to default value of the iiop-openjdk wildfly setting support-ssl being false (see iiop-openjdk/src/main/java/org/wildfly/iiop/openjdk/IIOPSubsystemAdd.java). But the code which handles the keepalive property is only found in DefaultSocketFactoryImpl of opendk-orb module, so it is basically never executed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/WFCORE-944?page=com.atlassian.jira.plugi... ] Ricardo Martin Camarero edited comment on WFCORE-944 at 6/19/20 10:39 AM: -------------------------------------------------------------------------- I stumbled on this a few days ago working on another JIRA. I implemented not long ago a PKCS12 test [HTTPSManagementInterfacePKCS12TestCase.java|https://github.com/wildfly/wildfly-core/blob/master/testsuite/manualmode/src/test/java/org/wildfly/core/test/standalone/mgmt/HTTPSManagementInterfacePKCS12TestCase.java] and I think it's easy to complete that test to also set the keystore-provider to all the keystores and test Darran's fix. I'll provide a new PR the next week. was (Author: rhn-support-rmartinc): I stumbled into this a few days ago working on another JIRA. I implemented not long ago a PKCS12 test [HTTPSManagementInterfacePKCS12TestCase.java|https://github.com/wildfly/wildfly-core/blob/master/testsuite/manualmode/src/test/java/org/wildfly/core/test/standalone/mgmt/HTTPSManagementInterfacePKCS12TestCase.java] and I think it's easy to complete that test to also set the keystore-provider to all the keystores and test Darran's fix. I'll provide a new PR the next week. > truststore path is ignored if provider is not JKS > ------------------------------------------------- > > Key: WFCORE-944 > URL: https://issues.redhat.com/browse/WFCORE-944 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Arto Huusko > Assignee: Ricardo Martin Camarero > Priority: Major > > truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS. > This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working. > We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured. > Even standard java supports PKCS12 truststores, where the same problem would occur. > So I would suggest that > - if provider is JKS, path is mandatory > - if provider is not JKS, but path is specified, it is passed to the provider -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/WFCORE-944?page=com.atlassian.jira.plugi... ] Ricardo Martin Camarero commented on WFCORE-944: ------------------------------------------------ I stumbled into this a few days ago working on another JIRA. I implemented not long ago a PKCS12 test [HTTPSManagementInterfacePKCS12TestCase.java|https://github.com/wildfly/wildfly-core/blob/master/testsuite/manualmode/src/test/java/org/wildfly/core/test/standalone/mgmt/HTTPSManagementInterfacePKCS12TestCase.java] and I think it's easy to complete that test to also set the keystore-provider to all the keystores and test Darran's fix. I'll provide a new PR the next week. > truststore path is ignored if provider is not JKS > ------------------------------------------------- > > Key: WFCORE-944 > URL: https://issues.redhat.com/browse/WFCORE-944 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Arto Huusko > Assignee: Ricardo Martin Camarero > Priority: Major > > truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS. > This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working. > We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured. > Even standard java supports PKCS12 truststores, where the same problem would occur. > So I would suggest that > - if provider is JKS, path is mandatory > - if provider is not JKS, but path is specified, it is passed to the provider -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13354) Add Galleon layers for the EJB subsystem

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13354?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFLY-13354: ----------------------------------------- FYI I don't think it should impact this specific task but I have recently been working on trying to convert some external projects to use slimmed servers provisioned by Galleon. At the moment it appears the correct handling of JACC permissions for a deployment depends upon the legacy security subsystem, this has not been very noticeable as ejb3 was not in a layer so the whole feature pack needed to be provisioned but once the ejb3 subsystem is in a layer it will make it easier to provision without legacy security. > Add Galleon layers for the EJB subsystem > ---------------------------------------- > > Key: WFLY-13354 > URL: https://issues.redhat.com/browse/WFLY-13354 > Project: WildFly > Issue Type: Feature Request > Components: Build System, EJB > Reporter: Brian Stansberry > Assignee: Cheng Fang > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/WFCORE-944?page=com.atlassian.jira.plugi... ] Ricardo Martin Camarero reassigned WFCORE-944: ---------------------------------------------- Assignee: Ricardo Martin Camarero > truststore path is ignored if provider is not JKS > ------------------------------------------------- > > Key: WFCORE-944 > URL: https://issues.redhat.com/browse/WFCORE-944 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Arto Huusko > Assignee: Ricardo Martin Camarero > Priority: Major > > truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS. > This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working. > We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured. > Even standard java supports PKCS12 truststores, where the same problem would occur. > So I would suggest that > - if provider is JKS, path is mandatory > - if provider is not JKS, but path is specified, it is passed to the provider -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13605) Fix licenses in full-feature-pack-licenses.xml

by Roberto Oliveira (Jira)

Roberto Oliveira created WFLY-13605: --------------------------------------- Summary: Fix licenses in full-feature-pack-licenses.xml Key: WFLY-13605 URL: https://issues.redhat.com/browse/WFLY-13605 Project: WildFly Issue Type: Bug Reporter: Roberto Oliveira Assignee: Roberto Oliveira Fix licenses in full-feature-pack-licenses.xml for the following artifacts - com.github.fge:btf Missing Apache license, see https://github.com/fge/btf/blob/1.2/LICENSE - com.github.fge:msg-simple Missing Apache License, see https://github.com/fge/msg-simple/blob/1.1/LICENSE - com.sun.istack:istack-commons-runtime and com.sun.istack:istack-commons-tools Remove wrong license, see: https://github.com/eclipse-ee4j/jaxb-istack-commons/blob/3.0.10/istack-co... - com.sun.xml.bind.external:relaxng-datatype Remove wrong license, see: https://github.com/eclipse-ee4j/jaxb-ri/blob/2.3.3-b02-RI/jaxb-ri/pom.xml... - org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.3_spec Replace the license for the correct one, see: https://github.com/jboss/jboss-jakarta-jax-ws-api_spec/blob/2.0.0.Final/a... -- 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 Diana Vilkolakova (Jira)

[ https://issues.redhat.com/browse/ELY-1998?page=com.atlassian.jira.plugin.... ] Diana Vilkolakova commented on ELY-1998: ---------------------------------------- [~rlucente-se-jboss] Do you by any chance have some experience with FIPS BC configuration on JDK11 ? Is it possible to setup default SecureRandom in java.security file? > 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

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