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 (55)
• personal (39)
• ramblings (2)
• rheinjug (2)
• ruhrjug (2)
• unsorted (9)

About Me Homepage Family Articles Talks
My PGP key

Categories Archive

• adjusted the NUnit 3.x constraints so they should work for NUnit 4.x as well.
  Issue #40.
• add a new ElementSelectors.ByNameAndAllAttributes variant that filters attributes before deciding whether elements can be compared.
  Inspired by Issue #xmlunit/259
• Nodes.GetMergedNestedText and Nodes.StripElementContentWhitespace had the same problem of not knowning about XmlWhitespace that caused Issue #38. And neither of the methods could deal with XmlSignificantWhitespace at all.
• add XmlWhitespaceStrippedSource, XmlWhitespaceNormalizedSource, and XmlElementContentWhitespaceStrippedSource that only trim characters that are considered whitespace by the XML Specification from textual content.
  Also added new modifiers to DiffBuilder that make use of the new ISource types.
  Issue #39.

path: /en/oss/XMLUnit | #

• oss
• XMLUnit

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