Hello, I think this is a valuable component.
We had created our own variant of that a while back and had quite a few challenges. We might not encounter all of them anymore (with modern Java), but on the other hand it can get tricky regardless: - changing support for discovery and lookup in different JAX-P (aka minor Java) versions - Different implementations with different level of feature support (Xerces built in, Xerces external, crimson, Woodstock, ..) - Support for different class loaders (OSGi, app servers, TCCL) - Different modes (disallow DTD or not, with validation, namespace support or xinclude) - Various factories (SAX Parser, Reader, StAX, DOM and third party JDOM) In our (maybe too complicated) design we used a few profiles for selecting the xml support wanted, since it also influences what you need to configure. For example if you can’t turn off DTD declarations, then you might need a custom (safe) resolver for entities. I don’t know if I remember all those points we encountered but I can at least contribute. Btw there is a secondary dimension about limits, not sure if we want to address this, since it’s quite implementation specific and modern implementations should have sane defaults if FSP is enabled. But it IS crucial if you want to process untrusted XML (especially with DOM or XSLT). Some basic questions: do we want to stay on the safe side and only provide known-good implementations or do we go the route of turning on as much protections as we know without restricting the implementations? Do we want to cover the discovery? Do we need a drop in factory or will we use a static factory method instead? How to deal with external dependencies - in my case JDOM1 is still an issue but I guess we don’t need support for such a legacy API? Gruß Bernd Gary Gregory schrieb am 18. Dez 2025 23:47 (GMT +01:00): > On Thu, Dec 18, 2025 at 5:27 PM Piotr P. Karwasz > <[email protected]> wrote: >> >> >> Hi Romain, >> >> On 18.12.2025 20:56, Romain Manni-Bucau wrote: >> > Since the secure configuration is implementation independent, will the >> > project just create N modules with one per implementation supported? >> > What is the plan? >> > Will it decorate all "factory" and provide its own SPI impl to not >> create >> > yet another API? >> >> >> I haven’t fully worked out the details yet, but the rough idea I had in >> mind was something along the lines of Commons Logging: >> >> - A small public API with one factory method per parser type >> (e.g. newDocumentBuilderFactory()). >> - A set of SPIs allowing a different secure configuration logic for each >> JAXP implementation. >> - A small number of bundled implementations covering the “surviving” >> parsers in practice (Xerces, the JDK’s Xerces fork, Woodstox). > > I'm glad we're talking about it because this is completely different > from what I had in mind: A small set of classes, maybe a single class. > Not a framework on top of JAXP or specific parsers... I guess we > should start looking at more specific examples in code... > > Gary > >> >> >> > 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. >> >> >> In theory, it’s only a handful of lines to harden a parser, and many >> projects did this years ago. In practice, some projects still get these >> details wrong. >> >> Even if the library ultimately served as a single, well-defined >> “scapegoat” for XXE reports, that alone would help the remediation >> process: you would just need to upgrade a single dependency instead of >> several. >> >> One area where I see a problem today is exception handling when >> configuring features. The common pattern is to log and ignore >> exceptions, but an unsupported feature can mean very different things: >> >> - The implementation genuinely does not support the potentially >> dangerous capability at all (e.g. external entities are impossible). >> - The implementation does support it, but exposes it under different >> feature or property names. >> >> Piotr >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > Gruß Bernd — https://bernd.eckenfels.net --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
