[JBoss JIRA] (WFLY-13763) WS-Sec Regression with WFLY18+ following upgrade to SAAJ 1.4
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13763:
---------------------------------------
Summary: 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
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)
5 years, 11 months
[JBoss JIRA] (DROOLS-4930) [DMN Designer] Remove UUID from Alerts panel validation messages
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-4930?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-4930:
----------------------------------------
I believe the original request was for the _*UUID to not be displayed in the Alert panel*_.
I do not believe the original request was ever to "remove UUID from Stunner", especially if that is of support of actual functionalities!
The thing is when the Alert is displayed in the alert panel on the lower part of the DMN editor, the UUID takes up like 30% of the real estate on the screen and that is totally wasteful, not to mention annoying for the end user who is not concerned with the UUID, but cares about the human friendly message.
> [DMN Designer] Remove UUID from Alerts panel validation messages
> -----------------------------------------------------------------
>
> Key: DROOLS-4930
> URL: https://issues.redhat.com/browse/DROOLS-4930
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.31.0.Final
> Reporter: Michael Anstis
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2020-01-17 07-41-57.png
>
>
> Validation of a DMN diagram can lead to messages being shown in the Alerts Panel.
> Stunner is appending the UUID to the message. See [CoreTranslationMessages.getElementValidationMessage()|https://github.com/...]
> [~tirelli] has requested their removal.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-4674) Custom handlers, formatters and filters cause the server to crash if the log manager is on the boot class path
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-4674?page=com.atlassian.jira.plug... ]
James Perkins commented on WFCORE-4674:
---------------------------------------
[~francisco.melojr] I'm not really sure if it was or not. This won't be available until WildFly 21.
> Custom handlers, formatters and filters cause the server to crash if the log manager is on the boot class path
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4674
> URL: https://issues.redhat.com/browse/WFCORE-4674
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Critical
> Labels: OpenShift, jdk11
> Fix For: 13.0.0.Beta1
>
>
> If the log manager is on the boot class path with Java 11, {{-Xbootclasspath/a:jboss-logmanager.jar}}, and a custom handler, formatter or filter is used the server will fail to boot as the log manager can't see the types in jboss-modules. This seems due to the fact that the log manager is on the boot class path and jboss-modules is on the system class path.
> Example exception:
> {code}
> Failed to read or configure the org.jboss.logmanager.LogManager
> java.lang.IllegalArgumentException: Failed to load module "org.jboss.logmanager" for formatter "JSON"
> at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:65)
> at org.jboss.logmanager.config.FormatterConfigurationImpl.<init>(FormatterConfigurationImpl.java:30)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.addFormatterConfiguration(LogContextConfigurationImpl.java:172)
> at org.jboss.logmanager.PropertyConfigurator.configureFormatter(PropertyConfigurator.java:631)
> at org.jboss.logmanager.PropertyConfigurator.configureHandler(PropertyConfigurator.java:701)
> at org.jboss.logmanager.PropertyConfigurator.configureLogger(PropertyConfigurator.java:583)
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:521)
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:97)
> at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:170)
> at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:132)
> at java.util.logging.LogManager$3.run(LogManager.java:399)
> at java.util.logging.LogManager$3.run(LogManager.java:396)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:396)
> at java.util.logging.LogManager.access$800(LogManager.java:145)
> at java.util.logging.LogManager$2.run(LogManager.java:345)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:338)
> at java.util.logging.LogManager.getLogManager(LogManager.java:378)
> at org.jboss.modules.Main.main(Main.java:523)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/modules/ModuleLoader
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$ModuleFinder.getClassLoader(AbstractPropertyConfiguration.java:556)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:63)
> ... 19 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (JGRP-2470) JBDC_PING can face a split-brain issue when restarting a coordinator node
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2470?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2470.
----------------------------
Resolution: Done
I fixed this in the {{master}} and {{4.x}} branches.
> JBDC_PING can face a split-brain issue when restarting a coordinator node
> -------------------------------------------------------------------------
>
> Key: JGRP-2470
> URL: https://issues.redhat.com/browse/JGRP-2470
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9, 4.0.22
> Reporter: Masafumi Miura
> Assignee: Radoslav Husar
> Priority: Major
> Fix For: 4.2.5, 5.0.1
>
>
> After [the change|https://github.com/belaban/JGroups/commit/215cdb6] for JGRP-2199, JDBC_PING deletes all entries from the table during the shutdown of the coordinator node.
> This behavior has a possibility to cause a split-brain when restarting a coordinator node. Because, as all entries are lost in the following scenario, the restarting node can not find any information about existing nodes from the table and does not form a cluster.
> 0. node1 and node2 form a cluster. The node1 is a coordinator.
> 1. Trigger a restart of the node1
> 2. The node1 removes their node information from the table
> 3. The node2 becomes a new coordinator
> 4. The node2 updates their node information in the table
> 5. The node1 clears all entries from the table
> 6. The node1 starts again
> 7. The node1 does not join the existing cluster because there's no node information in the table
> Note: If step 5 happens before step 4, the split-brain issue does not happen. However, as step 4 and step 5 happen on different nodes, these steps can happen in parallel. So, the order is undefined. So, for example, if the shutdown of node1 takes a long time, there's a high possibility to face this issue.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (JGRP-2470) JBDC_PING can face a split-brain issue when restarting a coordinator node
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2470?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2470 at 8/11/20 10:58 AM:
----------------------------------------------------------
OK, so {{removeAll()}} is only called when {{is_coord}} is true. So I suggest instead to set {{is_coord}} to false in {{super.stop()}} ({{Discovery}}). This is in line with setting {{is_server}} to false in {{Discovery}}.
Testing...
This works, as in step 5, {{is_coord}} will be false, so {{removeall()}} is not called.
was (Author: belaban):
OK, so {{removeAll()}} is only called when {{is_coord}} is true. So I suggest instead to set {{is_coord}} to false in {{super.stop()}} ({{Discovery}}). This is in line with setting {{is_server}} to false in {{Discovery}}.
Testing...
> JBDC_PING can face a split-brain issue when restarting a coordinator node
> -------------------------------------------------------------------------
>
> Key: JGRP-2470
> URL: https://issues.redhat.com/browse/JGRP-2470
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9, 4.0.22
> Reporter: Masafumi Miura
> Assignee: Radoslav Husar
> Priority: Major
> Fix For: 4.2.5, 5.0.1
>
>
> After [the change|https://github.com/belaban/JGroups/commit/215cdb6] for JGRP-2199, JDBC_PING deletes all entries from the table during the shutdown of the coordinator node.
> This behavior has a possibility to cause a split-brain when restarting a coordinator node. Because, as all entries are lost in the following scenario, the restarting node can not find any information about existing nodes from the table and does not form a cluster.
> 0. node1 and node2 form a cluster. The node1 is a coordinator.
> 1. Trigger a restart of the node1
> 2. The node1 removes their node information from the table
> 3. The node2 becomes a new coordinator
> 4. The node2 updates their node information in the table
> 5. The node1 clears all entries from the table
> 6. The node1 starts again
> 7. The node1 does not join the existing cluster because there's no node information in the table
> Note: If step 5 happens before step 4, the split-brain issue does not happen. However, as step 4 and step 5 happen on different nodes, these steps can happen in parallel. So, the order is undefined. So, for example, if the shutdown of node1 takes a long time, there's a high possibility to face this issue.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (JGRP-2470) JBDC_PING can face a split-brain issue when restarting a coordinator node
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2470?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2470:
---------------------------
Fix Version/s: 5.0.1
> JBDC_PING can face a split-brain issue when restarting a coordinator node
> -------------------------------------------------------------------------
>
> Key: JGRP-2470
> URL: https://issues.redhat.com/browse/JGRP-2470
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9, 4.0.22
> Reporter: Masafumi Miura
> Assignee: Radoslav Husar
> Priority: Major
> Fix For: 4.2.5, 5.0.1
>
>
> After [the change|https://github.com/belaban/JGroups/commit/215cdb6] for JGRP-2199, JDBC_PING deletes all entries from the table during the shutdown of the coordinator node.
> This behavior has a possibility to cause a split-brain when restarting a coordinator node. Because, as all entries are lost in the following scenario, the restarting node can not find any information about existing nodes from the table and does not form a cluster.
> 0. node1 and node2 form a cluster. The node1 is a coordinator.
> 1. Trigger a restart of the node1
> 2. The node1 removes their node information from the table
> 3. The node2 becomes a new coordinator
> 4. The node2 updates their node information in the table
> 5. The node1 clears all entries from the table
> 6. The node1 starts again
> 7. The node1 does not join the existing cluster because there's no node information in the table
> Note: If step 5 happens before step 4, the split-brain issue does not happen. However, as step 4 and step 5 happen on different nodes, these steps can happen in parallel. So, the order is undefined. So, for example, if the shutdown of node1 takes a long time, there's a high possibility to face this issue.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-4674) Custom handlers, formatters and filters cause the server to crash if the log manager is on the boot class path
by Francisco De Melo Junior (Jira)
[ https://issues.redhat.com/browse/WFCORE-4674?page=com.atlassian.jira.plug... ]
Francisco De Melo Junior commented on WFCORE-4674:
--------------------------------------------------
Hey guys, was this tested/QA? I couldn't find it here. If that's the case is it in EAP 7.3?
> Custom handlers, formatters and filters cause the server to crash if the log manager is on the boot class path
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4674
> URL: https://issues.redhat.com/browse/WFCORE-4674
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Critical
> Labels: OpenShift, jdk11
> Fix For: 13.0.0.Beta1
>
>
> If the log manager is on the boot class path with Java 11, {{-Xbootclasspath/a:jboss-logmanager.jar}}, and a custom handler, formatter or filter is used the server will fail to boot as the log manager can't see the types in jboss-modules. This seems due to the fact that the log manager is on the boot class path and jboss-modules is on the system class path.
> Example exception:
> {code}
> Failed to read or configure the org.jboss.logmanager.LogManager
> java.lang.IllegalArgumentException: Failed to load module "org.jboss.logmanager" for formatter "JSON"
> at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:65)
> at org.jboss.logmanager.config.FormatterConfigurationImpl.<init>(FormatterConfigurationImpl.java:30)
> at org.jboss.logmanager.config.LogContextConfigurationImpl.addFormatterConfiguration(LogContextConfigurationImpl.java:172)
> at org.jboss.logmanager.PropertyConfigurator.configureFormatter(PropertyConfigurator.java:631)
> at org.jboss.logmanager.PropertyConfigurator.configureHandler(PropertyConfigurator.java:701)
> at org.jboss.logmanager.PropertyConfigurator.configureLogger(PropertyConfigurator.java:583)
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:521)
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:97)
> at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:170)
> at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:132)
> at java.util.logging.LogManager$3.run(LogManager.java:399)
> at java.util.logging.LogManager$3.run(LogManager.java:396)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:396)
> at java.util.logging.LogManager.access$800(LogManager.java:145)
> at java.util.logging.LogManager$2.run(LogManager.java:345)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:338)
> at java.util.logging.LogManager.getLogManager(LogManager.java:378)
> at org.jboss.modules.Main.main(Main.java:523)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/modules/ModuleLoader
> at org.jboss.logmanager.config.AbstractPropertyConfiguration$ModuleFinder.getClassLoader(AbstractPropertyConfiguration.java:556)
> at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:63)
> ... 19 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months