September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-344) Bootable JAR - SSL 8443 port doesn't work by default

by Marek Kopecky (Jira)

Marek Kopecky created WFWIP-344: ----------------------------------- Summary: Bootable JAR - SSL 8443 port doesn't work by default Key: WFWIP-344 URL: https://issues.redhat.com/browse/WFWIP-344 Project: WildFly WIP Issue Type: Bug Reporter: Marek Kopecky Assignee: Kabir Khan Attachments: ssl-war.war RFE jira: EAP7-1385 SSL 8443 port doesn't work by default on bootable jar *Steps to reproduce:* * start bootable jar (hollow jar) with jaxrs-server, microprofile-config, datasources, h2-default-datasource layers (you can check the same on WF) * deploy deployment with this simple deployment: {code:java} @Path("/ssl") public class SslResource { @Path("/hello") @GET public String hello() { return "Hello World!"; } } {code} * Make HTTP call by this client (use [this client.truststore|https://github.com/resteasy/Resteasy/blob/3.12/testsuit...]): {code:java} truststore = KeyStore.getInstance("jks"); try (InputStream in = new FileInputStream("/home/path/client.truststore")) { truststore.load(in, "123456".toCharArray()); } resteasyClientBuilder = (ResteasyClientBuilder) ClientBuilder.newBuilder(); resteasyClientBuilder.setIsTrustSelfSignedCertificates(false); resteasyClientBuilder = resteasyClientBuilder.disableTrustManager(); client = resteasyClientBuilder.trustStore(truststore).build(); Response response = client.target("https://127.0.0.1:8443/ssl-war/ssl/hello").request().get(); System.out.println("Response status: " + response.getStatus() + " (expected is 200)"); if (response.getStatus() == 200) { System.out.println("Output: " + response.readEntity(String.class)); } {code} * See the results: ** "Connection refused (Connection refused)" on bootable jar ** 200 response code on WF cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-342) Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response

by Marek Kopecky (Jira)

[ https://issues.redhat.com/browse/WFWIP-342?page=com.atlassian.jira.plugin... ] Marek Kopecky updated WFWIP-342: -------------------------------- Summary: Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response (was: RESTEasy JAXB end-point on bootable jar return unexpected 400 response) > Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response > --------------------------------------------------------------------- > > Key: WFWIP-342 > URL: https://issues.redhat.com/browse/WFWIP-342 > Project: WildFly WIP > Issue Type: Bug > Reporter: Marek Kopecky > Assignee: Jean Francois Denise > Priority: Blocker > > RFE link: EAP7-1385 > RESTEasy JAXB end-point on bootable jar return unexpected 400 response with these security params: > {code:xml} > <context-param> > <param-name>resteasy.document.secure.processing.feature</param-name> > <param-value>true</param-value> > </context-param> > <context-param> > <param-name>resteasy.document.secure.disableDTDs</param-name> > <param-value>false</param-value> > </context-param> > <context-param> > <param-name>resteasy.document.expand.entity.references</param-name> > <param-value>false</param-value> > </context-param> > {code} > Used layers: > * jaxrs-server > * microprofile-config > Although this test is security related, AFAIK this is not related with legacy-security/elytron configuration, because related params are used in javax.xml.parsers.DocumentBuilderFactory directly from RESTEasy. Anyway let me know if I'm wrong. > Steps to reproduce: > # use installed WF version with reasonable layers, eg: WF_VERSION=21.0.0.Beta1-SNAPSHOT # > # git clone git@github.com:marekkopecky/Resteasy.git -b bootable-jar-3-12-secure-processing > # cd Resteasy > # mvn install -DskipTests -Dcheckstyle.skip=true > # cd testsuite > # mvn install:install-file -Dpackaging=pom -Dfile=pom.xml -DpomFile=pom.xml > # cd integration-tests > # mvn clean install -Dts.bootable -Ddefault=false -Ddisable.microprofile.tests -Dserver.version=${WF_VERSION} -Dserver.home=placeholder -Dcheckstyle.skip=true -Denforcer.skip -Dcheckstyle.skip=true -Dmaven.test.redirectTestOutputToFile=false > I can move these steps outside of TS, but I believe that TS doesn't affects this bootable jar behaviour, so it doesn't seem to be necessary. > I see just this unexpected&suspicious console output although I'm not sure whether it's related or not: > {noformat} > [org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 189; External DTD: Failed to read external DTD 'SecureProcessing_external.dtd', because 'file' access is not allowed due to restriction set by the accessExternalDTD property.] > {noformat} > cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13819) Drop jipijapa-hibernate5x-legacy modules

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13819?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13819: -------------------------------- Issue Type: Task (was: Bug) > Drop jipijapa-hibernate5x-legacy modules > ---------------------------------------- > > Key: WFLY-13819 > URL: https://issues.redhat.com/browse/WFLY-13819 > Project: WildFly > Issue Type: Task > Components: Clustering, JPA / Hibernate > Affects Versions: 20.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > The region factory implementations contained with these module have been non-functional for several releases, since they never registered their implementations with Hibernate's service registry. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13819) Drop jipijapa-hibernate5x-legacy modules

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13819: ----------------------------------- Summary: Drop jipijapa-hibernate5x-legacy modules Key: WFLY-13819 URL: https://issues.redhat.com/browse/WFLY-13819 Project: WildFly Issue Type: Bug Components: Clustering, JPA / Hibernate Affects Versions: 20.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro The region factory implementations contained with these module have been non-functional for several releases, since they never registered their implementations with Hibernate's service registry. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined with JDK8 now

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ] Jan Stourac commented on WFWIP-339: ----------------------------------- Okay, just tried with a newer JDK8 version (this is not set as default in our CI yet): {code} $ /home/jstourac/jdks/jdk1.8.0_261/bin/java -version java version "1.8.0_261" Java(TM) SE Runtime Environment (build 1.8.0_261-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode) {code} and you are right - I cannot reproduce this neither anymore. Is this the JDK8 version you used? One of the possible reasons for different behavior here may be the fact that JDK8u261 version has ALPN support backported into it already. And as such server does not have to use https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io... anymore? > OpenSSL security provider seems to be used when not defined with JDK8 now > ------------------------------------------------------------------------- > > Key: WFWIP-339 > URL: https://issues.redhat.com/browse/WFWIP-339 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Jan Stourac > Assignee: Farah Juma > Priority: Major > Attachments: client.jks, server.jks, standalone-full.xml > > > It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. I also see this change of behavior only with JDK8. JDK11 works as expected! > Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: > {quote} > 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 > {quote} > This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8: > {code} > <server-ssl-contexts> > <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/> > </server-ssl-contexts> > <client-ssl-contexts> > <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/> > </client-ssl-contexts> > {code} > There are two questions from this: > # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? > # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Not to mention that we don't want to behave differently for JDK8 and JDK11. > Hope I don't have any misconfiguration in the configuration itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined with JDK8 now

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ] Jan Stourac commented on WFWIP-339: ----------------------------------- Hm, I've tried again now and still I can reproduce: # download build and unzip {code} $ md5sum wildfly-21.0.0.Beta1-SNAPSHOT.zip 9f24b4fc8d8acfbe7b9f7d3134eb6463 wildfly-21.0.0.Beta1-SNAPSHOT.zip {code} # download [^client.jks], [^server.jks] and [^standalone-full.xml] attachments and copy into the {{wildfly-21.0.0.Beta1-SNAPSHOT/standalone/configuration/}} # start server with: {code} JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_241 wildfly-21.0.0.Beta1-SNAPSHOT/bin/standalone.sh -c standalone-full.xml {code} # I can see following in the log: {code} 12:39:47,528 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-6) WFOPENSSL0002 OpenSSL Version OpenSSL 1.1.1g FIPS 21 Apr 2020 {code} My JDK info: {code} $ /home/jstourac/jdks/jdk1.8.0_241/bin/java -version java version "1.8.0_241" Java(TM) SE Runtime Environment (build 1.8.0_241-b07) Java HotSpot(TM) 64-Bit Server VM (build 25.241-b07, mixed mode) {code} My OpenSSL info: {code} $ openssl version OpenSSL 1.1.1g FIPS 21 Apr 2020 {code} > OpenSSL security provider seems to be used when not defined with JDK8 now > ------------------------------------------------------------------------- > > Key: WFWIP-339 > URL: https://issues.redhat.com/browse/WFWIP-339 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Jan Stourac > Assignee: Farah Juma > Priority: Major > Attachments: client.jks, server.jks, standalone-full.xml > > > It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. I also see this change of behavior only with JDK8. JDK11 works as expected! > Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: > {quote} > 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 > {quote} > This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8: > {code} > <server-ssl-contexts> > <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/> > </server-ssl-contexts> > <client-ssl-contexts> > <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/> > </client-ssl-contexts> > {code} > There are two questions from this: > # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? > # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Not to mention that we don't want to behave differently for JDK8 and JDK11. > Hope I don't have any misconfiguration in the configuration itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5608) Cannot use method chaining as source for facts

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5608?page=com.atlassian.jira.plug... ] Luca Molteni commented on DROOLS-5608: -------------------------------------- Thanks for reporting [~cchiru] this seems broken also in Drools legacy (non-executable model) can you confirm this? > Cannot use method chaining as source for facts > ---------------------------------------------- > > Key: DROOLS-5608 > URL: https://issues.redhat.com/browse/DROOLS-5608 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.42.0.Final > Reporter: Ciprian Chiru > Assignee: Luca Molteni > Priority: Major > > Given the sample rule below: > {code:java} > import java.util.*; > global java.util.Set controlSet; > rule "will execute per each Measurement having ID color" > no-loop > when > Measurement( id == "color", $colorVal : val ) > String() from Optional.of($colorVal).orElse("blah") > then > controlSet.add($colorVal); > end{code} > > Compiling the resulting model fails with: > {code:java} > .../target/generated-sources/drools-model-compiler/main/java/rules/Rules79f20b1c9ba841128eaf4b2dbb336819RuleMethods0.java:[24,129] cannot find symbol > [ERROR] symbol: variable $colorVal > [ERROR] location: class rules.Rules79f20b1c9ba841128eaf4b2dbb336819RuleMethods0{code} > Can be reproduced with _7.43.0-SNAPSHOT_ > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-343) Bootable JAR - FeaturePack element exposes misleading Galleon concepts

by Jean Francois Denise (Jira)

Jean Francois Denise created WFWIP-343: ------------------------------------------ Summary: Bootable JAR - FeaturePack element exposes misleading Galleon concepts Key: WFWIP-343 URL: https://issues.redhat.com/browse/WFWIP-343 Project: WildFly WIP Issue Type: Bug Reporter: Jean Francois Denise Assignee: Jean Francois Denise When providing a list of feature-packs, each feature-pack item can be configured in a way that is not applicable to Bootable JAR. Furthermore some default values are not correct. This comes from the fack that the featurePack item is shared with the galleon generic maven plugin that offers more capabilities than the bootable JAR. In order to simplify configuration of feature-pack elements the following changes are required in the wildfly-jar-maven-plugin: * Remove inherit-configs item. It is implicitly false. * Make inherit-packages false by default. * Remove included-configs and excluded-configs elements. In a bootable JAR context a single configuration can be included. * Introduce "included-default-config"=[name of included config, eg:standalone-microprofile.xml]. Used to identify the default configuration to include in the bootable JAR. * Remove transitive attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1209) Automate Workload's Istio Config tab

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1209: ------------------------------------- Summary: Automate Workload's Istio Config tab Key: SWSQE-1209 URL: https://issues.redhat.com/browse/SWSQE-1209 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan https://github.com/kiali/kiali-ui/pull/1901 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12836) Large allocations in EJBContextImpl#isCallerInRole

by Tomasz Adamski (Jira)

[ https://issues.redhat.com/browse/WFLY-12836?page=com.atlassian.jira.plugi... ] Tomasz Adamski reassigned WFLY-12836: ------------------------------------- Assignee: Tomasz Adamski > Large allocations in EJBContextImpl#isCallerInRole > -------------------------------------------------- > > Key: WFLY-12836 > URL: https://issues.redhat.com/browse/WFLY-12836 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 18.0.1.Final > Reporter: Philippe Marschall > Assignee: Tomasz Adamski > Priority: Major > Attachments: elytron_allocations_redacted.PNG, screenshot-1.png > > > In our application we have the need to know the roles of the current user. We would like to do this using Java / Jakarta EE APIs rather than rely on WildFly implementation classes. We do this by iterating over all roles, which we know statically, and calling {{EJBContext#isCallerInRole}} for each one. This seem to be a common technique, see [How to get user roles in a JSP / Servlet|https://stackoverflow.com/questions/344117/how-to-get-user-roles-...]. > That's about 100 roles for us. We were expecting that would be a lookup into a {{HashMap}} or similar with O(1) complexity and almost no allocations. > This however does not seem to be case as {{EJBContextImpl#isCallerInRole}} seems to do the role mapping for every call. This results in a large amount of allocations. In our case this completely dominates our allocation profile. See attached screenshot from JFR. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 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 September 2020