Stefan Bodewig's Weblog

Weblog Main Feeds

• Apache (108)
• D-JUG (1)
• Germany (9)
• Java (8)
• Lisp (1)
• Mac (5)
• Windows (1)
• basketball (3)
• books (1)
• crypto (3)
• dotNet (34)
• edutainment (2)
• games (2)
• geourl (1)
• humor (3)
• malware (9)
• oss (54)
• personal (39)
• ramblings (2)
• rheinjug (2)
• ruhrjug (2)
• unsorted (9)

About Me Homepage Family Articles Talks
My PGP key

Categories Archive

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 | #

• 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 TransformerFactorys 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 of TransformerFactory and TransformerFactoryConfigurer may help with that.
  Inspired by Issue #264.
• JAXPXPathEngine will now try to disable the execution of extension functions by default but uses XPathFactory#setProperty which is not available prior to Java 18. You may want to enable secure processing on an XPathFactory instance you pass to JAXPXPathEngine instead - and XPathFactoryConfigurer may help with that.

path: /en/oss/XMLUnit | #

• oss
• XMLUnit

Kicked off a discussion about the future of Apache Ivy at the Ant dev mailing list.

path: /en/Apache/Ivy | #

• 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 | #

• 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 NodeFilters.

Full list of changes:

• added NodeFilters#SatisfiesAll and SatifiesAny 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 | #

• oss
• XMLUnit