[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5103?page=com.atlassian.jira.plug... ]
Farah Juma commented on WFCORE-5103:
------------------------------------
[~mmazanek] Thanks for confirming! Did you want to assign this one to yourself to update the error message so it better describes the actual problem?
> Adding non existent and not required keystore fails
> ---------------------------------------------------
>
> Key: WFCORE-5103
> URL: https://issues.redhat.com/browse/WFCORE-5103
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 13.0.0.Beta6
>
>
> We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is:
> /subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}})
> Error:
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service.
> [ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}},
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails
by Martin Mazánek (Jira)
[ https://issues.redhat.com/browse/WFCORE-5103?page=com.atlassian.jira.plug... ]
Martin Mazánek commented on WFCORE-5103:
----------------------------------------
In this case the behaviour is correct. If the file does not exist, there is no way of decoding the correct keystore type without explicitly defining it or without having a default type for scenarios like this. Although the Exception thrown should be fixed to better describe the problem
> Adding non existent and not required keystore fails
> ---------------------------------------------------
>
> Key: WFCORE-5103
> URL: https://issues.redhat.com/browse/WFCORE-5103
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 13.0.0.Beta6
>
>
> We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is:
> /subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}})
> Error:
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service.
> [ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}},
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (DROOLS-5608) Cannot use method chaining as source for facts
by Ciprian Chiru (Jira)
[ https://issues.redhat.com/browse/DROOLS-5608?page=com.atlassian.jira.plug... ]
Ciprian Chiru commented on DROOLS-5608:
---------------------------------------
[~lucamolteni] , yes it is broken. Starting with version 7.32.0.Final which seems to have introduced some breaking changes.
it fails with:
{code:java}
2020-09-01 09:04:59,970 INFO [org.example.drools.service.RulesSession] (main) Message [id=1, kieBase=defaultKieBase, level=ERROR, path=[...]/target/classes/rules/dummy-rule.drl, line=-1, column=0
text=Unable to Analyse Expression Optional.of($colorVal).orElse("blah"):
class sun.reflect.generics.reflectiveObjects.TypeVariableImpl cannot be cast to class java.lang.reflect.ParameterizedType (sun.reflect.generics.reflectiveObjects.TypeVariableImpl and java.lang.reflect.ParameterizedType are in module java.base of loader 'bootstrap')]
{code}
> 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
[JBoss JIRA] (WFWIP-342) Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFWIP-342?page=com.atlassian.jira.plugin... ]
Jean Francois Denise commented on WFWIP-342:
--------------------------------------------
[~mkopecky], is it an issue also observed with pure galleon provisioning of the server? It could be an issue larger than just Bootable JAR packaging caused by the galleon provisioning of layers (jaxrs-server and microprofile-config).
> 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
[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 commented on WFWIP-342:
-------------------------------------
I also see similar behaviour on SecureProcessing2Test and ExternalParameterEntityTest tests from RESTEasy TS
> 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
[JBoss JIRA] (JGRP-2400) FRAG4: cache marshalled output with FragmentedMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2400?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2400:
---------------------------
Fix Version/s: 5.0.3
(was: 5.1)
> FRAG4: cache marshalled output with FragmentedMessage
> -----------------------------------------------------
>
> Key: JGRP-2400
> URL: https://issues.redhat.com/browse/JGRP-2400
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.3
>
>
> FRAG4 marshals a long message (that has *no array*) into smaller fragments, e.g. when frag_size==200, a 500 byte message is marshalled into 3 FragmentedMessages of sizes 200, 200 and 100.
> The first FragmentedMessage marshals the entire original message, but only writes the first 200 bytes to the output stream.
> The second FragmentedMessage also marshals the entire original message, and writes the second 200 bytes.
> The third message writes only the last 100 bytes.
> This means that the original message is marshalled 3 times.
> It might be faster to create an object that wraps the original message *and* a byte array, which represents the marshalled object. When marshalled for the first time, the byte array is created. The second and third time, no marshalling is performed, but instead, the FragmentedMessages access the byte array directly (at the given offsets/lengths).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (JGRP-2400) FRAG4: cache marshalled output with FragmentedMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2400?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2400:
--------------------------------
Premarshalling an object is conceptually similar to what the previous fragmentation protocols (\{{FRAG2}}, {{FRAG3}}) do, and causes unneeded/unwanted eager marshalling and memory allocation.
Serializing an object into PartialOutputStream, and the latter discarding the serialized bytes which don't fit into a range, is cheap.
> FRAG4: cache marshalled output with FragmentedMessage
> -----------------------------------------------------
>
> Key: JGRP-2400
> URL: https://issues.redhat.com/browse/JGRP-2400
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> FRAG4 marshals a long message (that has *no array*) into smaller fragments, e.g. when frag_size==200, a 500 byte message is marshalled into 3 FragmentedMessages of sizes 200, 200 and 100.
> The first FragmentedMessage marshals the entire original message, but only writes the first 200 bytes to the output stream.
> The second FragmentedMessage also marshals the entire original message, and writes the second 200 bytes.
> The third message writes only the last 100 bytes.
> This means that the original message is marshalled 3 times.
> It might be faster to create an object that wraps the original message *and* a byte array, which represents the marshalled object. When marshalled for the first time, the byte array is created. The second and third time, no marshalling is performed, but instead, the FragmentedMessages access the byte array directly (at the given offsets/lengths).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (JGRP-2400) FRAG4: cache marshalled output with FragmentedMessage
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2400?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2400.
----------------------------
Resolution: Won't Fix
See last comment
> FRAG4: cache marshalled output with FragmentedMessage
> -----------------------------------------------------
>
> Key: JGRP-2400
> URL: https://issues.redhat.com/browse/JGRP-2400
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> FRAG4 marshals a long message (that has *no array*) into smaller fragments, e.g. when frag_size==200, a 500 byte message is marshalled into 3 FragmentedMessages of sizes 200, 200 and 100.
> The first FragmentedMessage marshals the entire original message, but only writes the first 200 bytes to the output stream.
> The second FragmentedMessage also marshals the entire original message, and writes the second 200 bytes.
> The third message writes only the last 100 bytes.
> This means that the original message is marshalled 3 times.
> It might be faster to create an object that wraps the original message *and* a byte array, which represents the marshalled object. When marshalled for the first time, the byte array is created. The second and third time, no marshalling is performed, but instead, the FragmentedMessages access the byte array directly (at the given offsets/lengths).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (WFWIP-344) Bootable JAR - SSL 8443 port doesn't work by default
by Marek Kopecky (Jira)
[ https://issues.redhat.com/browse/WFWIP-344?page=com.atlassian.jira.plugin... ]
Marek Kopecky updated WFWIP-344:
--------------------------------
Attachment: ssl-war.war
> 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
> Priority: Blocker
> 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
[JBoss JIRA] (WFWIP-344) Bootable JAR - SSL 8443 port doesn't work by default
by Marek Kopecky (Jira)
[ https://issues.redhat.com/browse/WFWIP-344?page=com.atlassian.jira.plugin... ]
Marek Kopecky updated WFWIP-344:
--------------------------------
Description:
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 ([^ssl-war.war]):
{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]
was:
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]
> 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
> Priority: Blocker
> 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 ([^ssl-war.war]):
> {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