Scott Cantor schrieb:
Because we use it in WSS4J we always rely on the backward compatibility.
Changing the WSS4J code just to circumvent a problem would cause a major
effort to many applications that actually use WSS4J. Before changing
WSS4J we shall check if a fix in xmlsec is more appropriate.
If the issue is with how the XML is being serialized, that's your
responsibility, not xmlsec's. Namespace declarations can't be assumed. You
need to manage the DOM rigorously and with great attention to detail.
The fact that a lot of code in these Apache projects doesn't is exactly why
we did our own.
-- Scott
Looking at the change notes I don't see a relevant entry that explains which
changes could trigger this problem. As said the test case we use is already
several years old, runs perfectly with xmlsec unto and including version 1.4.1
and produces inter-operable XML documents that contain encrypted stuff (only
XML sec encryption is affected). Only using xmlsec 1.4.2 (leaving the rest
of the environment unchanged) triggers this problem.
Did we have a problem in the test case that somehow didn't show up because
of a specific handling (or even problem) in previous xmlsec versions? Sort
of -1 * -1 = +1 ? If so - what was changed in xmlsec that could cause this
behaviour?
Regards,
Werner
