ppkarwasz opened a new pull request, #41: URL: https://github.com/apache/commons-xml/pull/41
Hardens the `SAXTransformerFactory` extension surface (`newTransformerHandler`, `newTemplatesHandler`, `newXMLFilter`) so its products carry the same resolver floor as the standard TrAX entry points, addressing findings f003 and f004. Previously this surface was documented as out of scope. ## Changes ### Refactor: wrap the Saxon `TransformerFactory` like every other implementation Saxon's `TransformerFactory` now goes through the same `HardeningTransformerFactory` wrapper as Xalan/XSLTC to get the `FallbackIgnoreURIResolver` floor, instead of a bespoke resolver floor inside its `Configuration`. The only remaining difference is the empty-`Source` shape the floor returns for an unresolved reference: the default empty DOM document for other factories, `EmptySource.getInstance()` for Saxon, threaded through as a `Supplier<Source>` from the factory down onto every produced `Templates` and `Transformer`. `EmptySource` is Saxon's marker class to indicate that the result should be an empty element of the type expected by the caller (e.g. a text document, an XSLT document). It reduces the number of errors caused by ignored fetches. `SaxonProvider` keeps only the vendor-specific `Configuration` bits JAXP cannot express. The XPath configure path, which has no factory wrapper, keeps a `Configuration`-level floor but now reuses `FallbackIgnoreURIResolver`. Saxon class references stay confined to `SaxonProvider`, an optional dependency. ### Feature: harden the extension surface - `HardeningTransformerHandler` wraps the handler and its live transformer in a `HardeningTransformer`, so runtime `document()` during the handler's SAX-driven transform and through the `getTransformer()` bypass sits on the floor (the stock JDK's `newTransformerHandler(Templates)` does not inherit the factory resolver on its own). - `HardeningTemplatesHandler` returns a `HardeningTemplates` from `getTemplates()`, so `Transformer`s built from it carry the floor; `include`/`import` during the feed already resolve through the factory floor in all implementations. - `HardeningXMLFilter` replaces the implementation filters, which self-provision an unhardened input reader (the stock JDK's as early as `setContentHandler`) and cast a supplied `Templates` to their own type. It parses the input with a hardened parent reader installed on first parse (a caller-set parent is trusted configuration) and transforms through a `HardeningTransformer`. - `newTransformerHandler(Templates)` unwraps a `HardeningTemplates` before delegating: implementations cast `templates.newTransformer()` to their own `Transformer` type, so handing them the wrapper threw `ClassCastException`. ### Docs: bring the surface into scope The threat model's in-scope guarantee now covers the extension methods when the returned `TransformerFactory` exposes them; the out-of-scope and known-non-findings bullets for that surface are removed. The index page notes that the products carry the same hardening as the standard entry points, and that the SAX events fed into a handler and a caller-set filter parent remain caller configuration. ## Testing New `TransformerHandlerTest`, `TemplatesHandlerTest` and `XMLFilterTest` cover the surface on every TrAX execution, each with an unconfigured leak control. Shade-footprint expectations grow by the three new wrapper classes. Full surefire matrix (test-saxon, test-saxon-xerces, test-stockjdk, test-woodstox, test-xalan, test-xalan-xerces, test-xerces) green. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
