Right, the bug fix that converted over the digest in xmltooling.

Indeed:

$ port installed | grep xmltooling
xmltooling @3.2.4_0 (active)

I’m just running against the older version out of macports.

I have no particular plan to fix those tests any time soon, it’s wasted effort right now. They were never stable enough to run as part of the release. If I have to do another and have time I’ll look into it.

This is an SHA256 transition issue like . The following patch fixes Response20Test::testChildElementsMarshall:

The same problem affects samltest/data/signature/SAML2Assertion.xml, but there the actual signature will have to be regenerated as well. I don’t know yet whether other control XML files have similar issues.

How can this be platform specific? Does MacOS still default to using SHA1?

is the other report I know of about the tests failing on Linux, but that is xmltooling, not opensaml. Seems like xmltooling tests must have passed if you only saw a failure at this point though. Both sets pass on the Mac and I couldn’t even get them building on Red Hat last I tried, so I hadn’t gone back to them.

It continues to pass on the Mac, and the tests haven’t worked on Linux for some time based on what others continue to report.

I’m not sure how wise it is to ship xml-secutity-c 3.0 anywhere, that’s my fork and is incompatible with the older version, but I suppose if both packages were available it’s an option. Otherwise you’re likely to break any other packages that might be using it, hopefully none exist though.

I’d suggest testing against the existing version of xml-sec and see if that changes anything. I suspect it won’t, but if it did that would be a much more interesting result.