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]
