If you want to keep it simple you can do like cxf and only support one impl and fail if not the right one is discovered passed to the static utility doing the config...but will stay a jar with 6-7 LoC so not sure the effort is worth it, worse if je default is fine now
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 ven. 19 déc. 2025, 05:40, Bernd Eckenfels <[email protected]> a écrit : > 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] > >
