On Mon, Apr 27, 2026 at 12:18 PM Piotr P. Karwasz <[email protected]> wrote: > > Hi Elliotte, > > On 24.04.2026 13:06, Elliotte Rusty Harold wrote: > > That said, Xerces does not have sufficient developer participation > > at this time to promise quick resolution. That's one reason I'm so > > wary of adding new projects that have even less commitment. > > Xerces XML Commons does look like a natural home for this. If > participation is the blocker, I'd be happy to help on the infrastructure > side: SVN-to-Git conversion, modernizing the build. That's mechanical > work, but it's the kind of thing that lowers the bar for future > contributions.
The blocker right now is code review, not contribution. If people step up and start reviewing PRs and pressing the approve button (I've lost count of how many times someone has looked at a PR but refused to approve without offering any actionable feedback, or even said LGTM but not pressed the approve button) then maybe new contributions can start moving forward. The first step for anyone who wants to participate is to review PRs. There are some maintenance issues that need to be dealt with but these are all blocked on code review and permissions right now. > 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. -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
