In recent releases, the Base64 created in Santuario's XML signatures has changed from wrapped Base64 separated by Java newlines (\n) to wrapped Base64 separated by (\r\n) sequences. This happens only under Java 11 or later where Santuario uses the system-supplied Base64 encoder.
This is, arguably, correct according to the XML specification, although the same argument would inevitably lead to the conclusion that all XML generated by Java should have the same line separator sequences. I cannot agree with that conclusion, so the decision to change just this one aspect of the generated output seems to me to be extremely misguided. It's not going away, though.
We ran into the same problem with XMLSecTool and the IdP (see XSTJ-69 and
IDP-1313), but the solution adopted in those cases of setting an application-wide system property prior to initialising the Santuario library will not work for the MDA:
- The MDA is a framework and should not modify global behaviour in that way.
- The MDA probably isn't going to be invoked in such a way that the property can be reliably set before Santuario's initialisation.
- The result of that change is to remove the line separators entirely, so still involves a change in behaviour.
I think the correct approach here is to document the change in behaviour, and the potential use of the system property by the invoker to change the behaviour globally. MDA users may need to tweak the output (by stripping CRs) to get the same output as they had before, if it matters to them (the UKf already runs such a normaliser for the cases in which the MDA is running under Windows and text files have those separators anyway).
So where's the bug? In the MDA's tests, which are running up against the fact that the CR is inserted as text and because it is not output-and-then-input, does not get stripped out prior to comparison with the expected text.
We need to fix the tests, and document the change in behaviour.