On Thu, Dec 18, 2025, 14:58 Romain Manni-Bucau <[email protected]> wrote:
> Hi, > > Since the secure configuration is implementation independent, will the > project just create N modules with one per implementation supported? > Not at all. What is the plan? > What Piotr discovered (please correct me if I'm mischaracterizing what we discussed) is that all current major Java version implementations of JAXP all the way back to Java 7 enable what JAXP calls "secure processing". In the past, you had to explicitly enable this feature with an API call. Today you don't. Except when you deal with an old non-stock JAXP implementation like Apache Xerces. What we've been doing in places like Commons Text is asking for secure processing by default for XML parsing and XPath evaluation. This is really a no-op for JAXP implementations in stock Java. But, for 3rd party JAXP implementation like Xerces, it says "be secure now since your defaults are not.". I'm not sure what Saxon does. In addition, many static tools out there will flag your code as insecure if you don't enable this and that feature on your XML parser, which is now unnecessary since stock Java provides secure processing; but that doesn't stop these tools and people submitting reports of vulnerabilities, asking for CVEs and their name in lights. Piotr, did I summarize properly? HTH, Gary Will it decorate all "factory" and provide its own SPI impl to not create > yet another API? > > The risk is to create something more bothering than helping since it is > literally 7-8 lines to make it fixed and most projects did 7-8 years ago so > wonder the added value today. > > Romain Manni-Bucau > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> > | Old > Blog <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > Javaccino founder (Java/.NET service - contact via linkedin) > > > Le jeu. 18 déc. 2025 à 19:05, Gary Gregory <[email protected]> a > écrit : > > > On Thu, Dec 18, 2025, 12:37 Elliotte Rusty Harold <[email protected]> > > wrote: > > > > > I'm not sure what is needed for XPathFactory. I've never seen any > > > issue involving that. This is the sort of question a detailed proposal > > > could answer. > > > > > > > We've already had to deal with this exact issue in Commons Text because > > enabling secure processing for document parsing is separate from enabling > > it for XPath evaluation. Piotr and I took a deep dive into this topic > which > > then engendered the idea for this new component. > > > > HTH, > > Gary > > > > > > > > > On Thu, Dec 18, 2025 at 1:35 PM Piotr P. Karwasz > > > <[email protected]> wrote: > > > > > > > > Hi all, > > > > > > > > Given the recent surge in low-quality XXE security reports on the one > > > > hand, and the emergence of CVEs such as CVE-2025-54988 in Apache Tika > > > > on the other [1], I would like to propose a new Apache Commons > project: > > > > > > > > Commons JAXP > > > > > > > > The initial scope would be deliberately narrow: to provide builders > > > > that securely configure, in an implementation-independent manner, the > > > > following Java API for XML Processing (JAXP) factories: > > > > > > > > - DocumentBuilderFactory (DOM) > > > > - SAXParserFactory (SAX) > > > > - XMLInputFactory (StAX) > > > > - TransformerFactory (TraX) > > > > - XPathFactory (XPath) > > > > > > > > It seems unreasonable that in 2025 developers are still expected to > > > > manually apply the same sets of configuration flags copied from > > > > cheat sheets (such as OWASP [2]), which have effectively been > outdated > > > > for more than a decade. > > > > > > > > In 2013, JEP 185 [3] introduced a set of system properties that > define > > > > the allowlist of protocols JAXP implementations may use to retrieve > > > > external resources. For the default JDK implementations, these lists > > > > are effectively empty for DOM and SAX (and, somewhat unexpectedly, > > > > set to "all" for StAX). > > > > > > > > However, introducing an older or alternative JAXP implementation on > > > > the classpath (for example, Xerces) bypasses these safeguards and > > > > reintroduces the very issues developers believe they are protected > > > > against. > > > > > > > > A small, focused library could address this by: > > > > > > > > - Eliminating widespread duplication of JAXP hardening code across > > > > countless libraries and applications. > > > > - Providing a single, well-understood location for handling XXE > > > > concerns, so that any future reports are directed at Commons JAXP > > > > rather than hundreds of downstream projects. > > > > > > > > What do you think? > > > > > > > > Piotr > > > > > > > > [1] https://www.cve.org/CVERecord?id=CVE-2025-54988 > > > > [2] > > > > > > > > > > https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#java > > > > [3] https://openjdk.org/jeps/185 > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > -- > > > Elliotte Rusty Harold > > > [email protected] > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > >
