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). > 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]
