XMLSignatureSigningStage output changes with Java 11 and latest Santuario
Description
Environment
is related to
Activity
Ian YoungDecember 10, 2020 at 2:18 PM
Appears to be an issue in Red Hat's OpenJDK 8 distribution as of 8u272, but may have been introduced earlier.
Ian YoungOctober 17, 2019 at 3:36 PM
Changed the back-port to maint-0.9 to loosen the canary check, as Oracle Java 8u231 now has the same behaviour as Java 11.
Commit d541e071595255c97164055044457283aeec923e on maint-0.9.
No changes required to master as it requires Java 11.
Ian YoungJanuary 29, 2019 at 4:46 PM
Fixed in master commit 364d6d23ee7e40487035d68f35fd7b64ba65d420.
Back-ported to the maint-0.9 branch to allow the Jenkins "multi" job to continue to function under Java 11, commit 4f05c3e1fef72d84d69cd3062e6ab8e71fe52e56.
Ian YoungJanuary 28, 2019 at 11:23 AM
I agree that the specs (principally XML Schema, which says that Base64 can contain CRs as well as various other kinds of whitespace) allow CRs in the signature. The fact that they are serialised to is "just" ugly and unexpected from this point of view. The same reasoning could however be applied to signature output containing 50 line separators between lines, or the entire text of War and Peace in an XML comment, so it's not very persuasive in terms of telling me what the output should look like.
Stipulating for now that there's no spec violation here, the question becomes whether this specific behaviour is acceptable to the MDA userbase, and I don't think it is. People eyeball the output of this stuff on a regular basis, unlike with most signatures generated by the IdP.
Note that I had a different opinion when I thought that the result was just going to be some surplus CRs in serialised output; I have gone 180 degrees now that I realise we're actually talking about regularly producing files containing '&', '#', '1', '3', ';' sequences. The MDA has to _not_ do that by default.
I don't see any route to getting the output I claim we want without scrubbing CRs from the elements containing them, so that's what I am going to do. I will wrap that in a boolean property so that if I mess up the implementation somehow people will at least have the option of disabling the scrubbing and getting whatever Santuario produces.
Scott CantorJanuary 25, 2019 at 10:16 PM
I wouldn't personally advocate any sort of automatic removal of the characters, but like with much of the MDA, it's all about producing customized output to meet your requirements, so I suppose it's not hard to imagine wanting the ability to do it.
But tests aside, you're not getting bad data out, you just have to convince yourself that the signatures are intact if you don't believe me.
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 and ), 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.