I took a look, please see my comment. Colm.
On Wed, Mar 5, 2025 at 8:47 AM FABIAN Lukas <lukas.fab...@svc.co.at> wrote: > > Hi, > > > I opened a pull request which fixes this issue (#453), could someone review > this? > > > > ________________________________ > From: FABIAN Lukas > Sent: Monday, 13 January 2025 08:22 > To: dev@santuario.apache.org > Subject: AW: Digest verification fails with SAAJ 1.4+ > > [Sie erhalten nicht häufig E-Mails von lukas.fab...@svc.co.at. Weitere > Informationen, warum dies wichtig ist, finden Sie unter > https://aka.ms/LearnAboutSenderIdentification ] > > Hi, > > I have created a simple soap service where the issue can be reproduced. Run > the main class and then start the unit test, it will fail with the error > "Signature cryptographic validation not successful". > > > -----Ursprüngliche Nachricht----- > Von: Colm O hEigeartaigh <cohei...@apache.org> > Gesendet: Dienstag, 7. Jänner 2025 13:04 > An: dev@santuario.apache.org > Betreff: Re: Digest verification fails with SAAJ 1.4+ > > [Sie erhalten nicht häufig E-Mails von cohei...@apache.org. Weitere > Informationen, warum dies wichtig ist, finden Sie unter > https://aka.ms/LearnAboutSenderIdentification ] > > Hi, > > Is it possible to reproduce the issue in a unit test (or even a > standalone testcase)? > > Colm. > > On Tue, Jan 7, 2025 at 11:29 AM FABIAN Lukas <lukas.fab...@svc.co.at> wrote: > > > > Hi, > > > > > > > > I have an issue with digest verification when using SAAJ versions newer > > than 1.3. In general my issue is very similar to SANTUARIO-576. > > > > > > > > With SAAJ 1.3 everything works as intended, but if I use SAAJ 1.4 (or any > > newer version, e.g. 3.0.4), the digest verification fails. After some > > investigation, I noticed that with the new versions there is a type > > mismatch in org.apache.xml.security.c14n.implementations.CanonicalizerBase > > which leads to the Signature element not being removed, thus calculating a > > wrong digest value. > > > > The relevant code is from line 242 onwards: > > case Node.ELEMENT_NODE : > > > > documentLevel = NODE_NOT_BEFORE_OR_AFTER_DOCUMENT_ELEMENT; > > > > if (currentNode == excludeNode) { > > > > break; > > > > } > > > > > > > > In my case excludeNode is of type > > com.sun.xml.messaging.saaj.soap.impl.ElementImpl and currentNode is of type > > com.sun.org.apache.xerces.internal.dom.ElementNSImpl. Therefore, the > > condition currentNode == excludeNode is not true and the excludeNode is not > > removed. > > > > The behaviour seems to have changed with SAAJ 1.4 because ElementImpl is no > > longer extending com.sun.org.apache.xerces.internal.dom.ElementNSImpl. It > > now has a private element field to store a reference to the actual Element. > > > > > > > > A fix for my issue would be replacing > > > > if (currentNode == excludeNode) > > > > with > > > > if (excludeNode != null && > > excludeNode.isSameNode(currentNode)) > > > > > > > > but maybe there are better fixes. Especially the case from the Jira Ticket, > > where the class types of currentNode and excludeNode are swapped, would not > > be fixed with my approach. > > > > > > > > Is it possible to fix this in a future version of Santuario? This issue is > > blocking the JBoss EAP8 migration of our application. > > > > > > > > Kind regards, > > > > Lukas Fabian
