XMLUnit for Java's Transform
's default transformation
allowed the use of XSLT extension functions - this has been changed in
2.10.0.
If you've been using XMLUnit to run XSLT transformations with untrusted stylesheets and your setup is so that an attacker can chose the stylesheet and ensure your XSLT processor can run the extensions this may lead to a remote code execution in the worst setup. Therefore the old default has been assigned CVE-2024-31573.
Some XSLT processors - e.g. Apache Xalan - allow the extension code to be specified inline with an Apache BSF enabled scripting language - note that would require your code executing the transformation to also have BSF around. In outher cases your transformation would need to allow the attacker to also inject Java classes into your running process. This combined with my believe that XMLUnit is very unlikely to be run in a setup like this made me set the impact to "Low".
Advisory: https://github.com/xmlunit/xmlunit/security/advisories/GHSA-chfm-68vv-pvw5
path: /en/oss/XMLUnit | #
- add a new
ElementSelectors.byNameAndAllAttributes
variant that filters attributes before deciding whether elements can be compared.
Inspired by Issue #259. - By default the
TransformerFactory
s created will now try to disable extension functions. If you need extension functions for your transformations you may want to pass in your own instance ofTransformerFactory
andTransformerFactoryConfigurer
may help with that.
Inspired by Issue #264. JAXPXPathEngine
will now try to disable the execution of extension functions by default but usesXPathFactory#setProperty
which is not available prior to Java 18. You may want to enable secure processing on anXPathFactory
instance you pass toJAXPXPathEngine
instead - andXPathFactoryConfigurer
may help with that.
path: /en/oss/XMLUnit | #
Kicked off a discussion about the future of Apache Ivy at the Ant dev mailing list.
path: /en/Apache/Ivy | #
Received a recruiter message last week that stood out from the others:
I'm getting in contact on behalf of X, the creators of Apache Y
Nonsense.
Even if I was looking for a new job I'd stop reading at that point. The creators of Apache Y are the project's contributors, not X. X may be the inventor but in my conrete combination of X and Y that wouldn't be true, either. X may employ some of the contributors, but it does not create Apache Y.
If you allow recruiters to use such a phrase you first demonstrate you don't understand how the ASF works and second are obviously willing to lie. Why would I want to work for an employer who lies to me?
path: /en/personal | #
I've just released a small minor release of XMLUnit.NET that fixes
a bug with whitespace normalization/stripping and adds a small feature
simplifying the use of NodeFilter
s.
Full list of changes:
- added
NodeFilters#SatisfiesAll
andSatifiesAny
methods to make it easier to combine multiple node filters.
added to simplify the use case of xmlunit/#249 - when documents contained element content whitespace represented by
System.Xml.XmlWhitespace
the types and methods that are supposed to strip or normalize whitespace would fail.
Issue #38
path: /en/oss/XMLUnit | #