Hi Elliotte, On 1.05.2026 12:47, Elliotte Rusty Harold wrote: >> There's some irony in proposing this under Xerces. The library exists in >> part because Xerces is, these days, a transitive-dependency footgun: >> pulling it in silently opts an application out of JEP 185's >> ACCESS_EXTERNAL_* restrictions, since Xerces stays faithful to the XML >> spec rather than the JDK's hardened interpretation of it. A library that >> hardens both implementations uniformly arguably belongs under the >> project that maintains the one most in need of the help. > > I am a little skeptical of this claim. The JDK does not have a good > record with XML conformance, and not just in issues about accessing > external entities. One reason I'd prefer to see this in Xerces is to > get some expert eyes on it that know what the XML spec says, and what > the issues actually are. Security issues reported around XML > processing are usually overhyped and misunderstood. They tend to come > from weak tools that don't understand what code is doing, and get > reported because they're easy for tools to detect, not because they're > significant. More important issues (including a few I can think of > baked into and encouraged by JDK APIs) get missed because they don't > have a shiny CVE attached to them for scanners to report to prove > they're doing something.
The JDK might not have XML conformance as a goal, but I think they did their homework on security. Of course: XML is very often just used as a configuration format and in that case the warnings from static analysis tools are just noise. However, there are concrete cases when developers forget to properly harden a factory (StAX defaults are notably unsafe) or a parser previously only used for trusted data is used to parse user-controlled XML. Unless specific XML features are required, it is better to start with a secure default. Anyway, following you suggestion, I have posted a message to `xml-commons-dev@xerces` to gather some feedback on the choices I made in my library: https://lists.apache.org/thread/lxwny26689r1cbmmj27s6gdrqp64lgsy Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
