[JBoss JIRA] (SWSQE-1089) Remove hardcoded waiting for webhook "smcp.validation.maistra.io"
by Hayk Hovsepyan (Jira)
[ https://issues.redhat.com/browse/SWSQE-1089?page=com.atlassian.jira.plugi... ]
Hayk Hovsepyan updated SWSQE-1089:
----------------------------------
Sprint: Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41, Kiali Sprint #42, Kiali Sprint #43, Kiali Sprint #44, Kiali Sprint #45 (was: Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41, Kiali Sprint #42, Kiali Sprint #43, Kiali Sprint #44)
> Remove hardcoded waiting for webhook "smcp.validation.maistra.io"
> -----------------------------------------------------------------
>
> Key: SWSQE-1089
> URL: https://issues.redhat.com/browse/SWSQE-1089
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Optional
> Labels: infrastructure
>
> https://gitlab.cee.redhat.com/istio/kiali-qe/kiali-qe-jenkins-dsl/blob/ma...
> There is no need to wait that long. We need some dynamic check.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (SWSQE-1056) Try OCP 4.6 on IPv6 in PSI
by Hayk Hovsepyan (Jira)
[ https://issues.redhat.com/browse/SWSQE-1056?page=com.atlassian.jira.plugi... ]
Hayk Hovsepyan updated SWSQE-1056:
----------------------------------
Sprint: Kiali Sprint #32, Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41, Kiali Sprint #42, Kiali Sprint #43, Kiali Sprint #44, Kiali Sprint #45 (was: Kiali Sprint #32, Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41, Kiali Sprint #42, Kiali Sprint #43, Kiali Sprint #44)
> Try OCP 4.6 on IPv6 in PSI
> --------------------------
>
> Key: SWSQE-1056
> URL: https://issues.redhat.com/browse/SWSQE-1056
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Major
> Labels: infrastructure
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (WFLY-13763) WS-Sec Regression with WFLY18+ following upgrade to SAAJ 1.4
by Andreas Weise (Jira)
[ https://issues.redhat.com/browse/WFLY-13763?page=com.atlassian.jira.plugi... ]
Andreas Weise commented on WFLY-13763:
--------------------------------------
Good to see, that there is an idea of how to fix it. do you think it can be fixed in WFLY21 ?
> WS-Sec Regression with WFLY18+ following upgrade to SAAJ 1.4
> ------------------------------------------------------------
>
> Key: WFLY-13763
> URL: https://issues.redhat.com/browse/WFLY-13763
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: Brian Stansberry
> Assignee: Jim Ma
> Priority: Major
>
> This was reported by Andreas Weise at https://groups.google.com/g/wildfly/c/B4Gk4ljbrqE:
> After upgrading to WFY20 we are facing a regression regarding WS-Security that was introduced with Upgrade of com.sun.xml.messaging.saaj:saaj-impl in https://issues.redhat.com/browse/WFLY-12442 with WFLY18. When downgrading com.sun.xml.messaging.saaj:saaj-impl to 1.3.x the regression is fixed also in WFLY18+. We did not locate the root cause in saaj-impl 1.4+.
> The Bug was spotted within our signing algorithm used for our SOAP Web Services (which uses javax.xml.crypto.dsig Packages).
> The Bug can be reproduced easily via https://github.com/weand/wildfly-xml-sig-reproducer, which contains the most basic reproducer code of our scenario:
> Reproducer contains a Web Service implementation which uses XML Signature and more specifically the enveloped-signature transform algorithm (https://www.w3.org/TR/xmldsig-core1/#sec-EnvelopedSignature). This standard transform algorithm basically removes the whole Signature element from the digest calculation. And thats not stable since WFLY18 as the Signature element is not removed anymore! The repo also contains an arquillian test testing the SOAP webservice response using rest-assured.
> Run good scenario: Test on WFLY17
> 1) mvn clean install -Pwfly17
> 2) Test passes
> 3) see proper 'Pre-digested input' as DEBUG output of org.apache.jcp Logger (here I pretty formatted the XML):
> {code}
> 17:58:04,494 DEBUG [org.apache.jcp.xml.dsig.internal.DigesterOutputStream] (default task-1) Pre-digested input:
> 17:58:04,494 DEBUG [org.apache.jcp.xml.dsig.internal.DigesterOutputStream] (default task-1) <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" ID="Body">
> <ns1:echoResponse
> xmlns:ns1="http://reproducer.sig.xml.wildfly.weand.github.com/">
> <return>hello test</return>
> </ns1:echoResponse>
> </soap:Body>
> 17:58:04,495 DEBUG [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) Reference object uri = #Body
> 17:58:04,495 DEBUG [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) Reference digesting completed
> {code}
> Run failing scenario: Test on WFLY18+
> 1) mvn clean install (which defaults to 20.0.1.Final)
> 2) Test fails
> {code}
> [ERROR] testService(com.github.weand.wildfly.xml.sig.reproducer.test.XmlSignatureIT) Time elapsed: 0.874 s <<< FAILURE!
> java.lang.AssertionError:
> Expected: Expected text value '0FCBFaURtUN+0kxupRbO3pp93rPY+9d1bf7ffAw77lQ=' but was 'A+XljxuKgY2Va+YDk/Ho66i/+JQLeA9QoTH8kap7Zdk=' - comparing <DigestValue ...>0FCBFaURtUN+0kxupRbO3pp93rPY+9d1bf7ffAw77lQ=</DigestValue> at /Envelope[1]/Body[1]/Signature[1]/SignedInfo[1]/Reference[1]/DigestValue[1]/text()[1] to <DigestValue ...>A+XljxuKgY2Va+YDk/Ho66i/+JQLeA9QoTH8kap7Zdk=</DigestValue> at /Envelope[1]/Body[1]/Signature[1]/SignedInfo[1]/Reference[1]/DigestValue[1]/text()[1]:
> <DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">0FCBFaURtUN+0kxupRbO3pp93rPY+9d1bf7ffAw77lQ=</DigestValue>
> but: result was:
> <DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">A+XljxuKgY2Va+YDk/Ho66i/+JQLeA9QoTH8kap7Zdk=</DigestValue>
> at com.github.weand.wildfly.xml.sig.reproducer.test.XmlSignatureIT.testService(XmlSignatureIT.java:71)
> {code}
> 3) see invalid 'Pre-digested input' as DEBUG output of org.apache.jcp Logger:
> {code}
> 18:03:42,888 DEBUG [org.apache.jcp.xml.dsig.internal.DigesterOutputStream] (default task-1) Pre-digested input:
> 18:03:42,888 DEBUG [org.apache.jcp.xml.dsig.internal.DigesterOutputStream] (default task-1) <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" ID="Body">
> <ns1:echoResponse
> xmlns:ns1="http://reproducer.sig.xml.wildfly.weand.github.com/">
> <return>hello test</return>
> </ns1:echoResponse>
> <Signature
> xmlns="http://www.w3.org/2000/09/xmldsig#">
> <SignedInfo>
> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></CanonicalizationMethod>
> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod>
> <Reference URI="#Body">
> <Transforms>
> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform>
> </Transforms>
> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod>
> <DigestValue></DigestValue>
> </Reference>
> </SignedInfo>
> <SignatureValue></SignatureValue>
> </Signature>
> </soap:Body>
> 18:03:42,888 DEBUG [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) Reference object uri = #Body
> 18:03:42,888 DEBUG [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) Reference digesting completed
> {code}
> Again the digest with enveloped-signature transform algorithm works properly when downgrading saaj-impl to 1.3.x in WFLY18+.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (WFCORE-5111) Upgrade JBoss MSC from 1.4.11 to 1.4.12
by Richard Opalka (Jira)
Richard Opalka created WFCORE-5111:
--------------------------------------
Summary: Upgrade JBoss MSC from 1.4.11 to 1.4.12
Key: WFCORE-5111
URL: https://issues.redhat.com/browse/WFCORE-5111
Project: WildFly Core
Issue Type: Component Upgrade
Components: Server
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: 13.0.0.Beta6
Brings in:
Fixes:
MSC-252 Removing double word of service in the thrown exception ServiceNotFoundException
Enhancements:
MSC-255 Deprecating StabilityMonitor & StabilityStatistics
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months
[JBoss JIRA] (WFWIP-344) Bootable JAR - SSL 8443 port doesn't work by default
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFWIP-344?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFWIP-344:
----------------------------------------
I would say the behaviour is the same across WildFly and bootable jar, the only difference is only a subset of layers is being provisioned here - the WildFly distribution on the other hand provisions a complete default.
For this specific example if you add the "undertow-legacy-https" layer to the list you should have the legacy realm definition and the HTTPS listener although we need to move this general approach into a more sustainable practice.
> 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: Jean Francois Denise
> 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)
3 years, 8 months
[JBoss JIRA] (WFWIP-344) Bootable JAR - SSL 8443 port doesn't work by default
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFWIP-344?page=com.atlassian.jira.plugin... ]
Jean Francois Denise commented on WFWIP-344:
--------------------------------------------
[~mkopecky], I think the same occurs with WildFly using galleon to provision these layers. If you want https enabled, you can use the default config. To do so don't set any galleon layers, standalone-microprofile.xml will be used. In this config we include the undertow-legacy-https (that relies on security-realm and self signed certificate).
> 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: Jean Francois Denise
> 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)
3 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 commented on WFWIP-344:
-------------------------------------
Do we want different behaviour in WF and bootable jar?
> 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: Jean Francois Denise
> 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)
3 years, 8 months
[JBoss JIRA] (WFWIP-344) Bootable JAR - SSL 8443 port doesn't work by default
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFWIP-344?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFWIP-344:
----------------------------------------
This sounds to be the expected behaviour, there is an example in the wildfly jar plugin project to active SSL so just sounds as though it is not activated.
> 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: Jean Francois Denise
> 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)
3 years, 8 months
[JBoss JIRA] (JGRP-2500) Throttle "no route to" log messages
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2500?page=com.atlassian.jira.plugin... ]
Bela Ban reassigned JGRP-2500:
------------------------------
Fix Version/s: 4.2.6
5.0.4
Assignee: Bela Ban
> Throttle "no route to" log messages
> -----------------------------------
>
> Key: JGRP-2500
> URL: https://issues.redhat.com/browse/JGRP-2500
> Project: JGroups
> Issue Type: Bug
> Reporter: Diego Lovison
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.6, 5.0.4
>
>
> When doing some put in a cache that has a backup site, if the backup site is not available, a lot of messages will be printed in logs. I think that we can count and print every 100 or 1000
> Current state:
> {noformat}
> [1;31m21:42:38,542 ERROR (jgroups-146,edg-perf05-62972) [org.jgroups.protocols.relay.RELAY2] edg-perf05-62972: no route to site01: dropping message[m
> [1;31m21:42:38,542 ERROR (irac-sender-thread-edg-perf05-62972) [org.jgroups.protocols.relay.RELAY2] edg-perf05-62972: no route to site01: dropping message[m
> {noformat}
> Desired state: dropping X messages
> {noformat}
> [1;31m21:42:38,542 ERROR (irac-sender-thread-edg-perf05-62972) [org.jgroups.protocols.relay.RELAY2] edg-perf05-62972: no route to site01: dropping X messages[m
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 8 months