ppkarwasz opened a new pull request, #69:
URL: https://github.com/apache/commons-secure-xml/pull/69

   The `URIResolver` floor answered every unresolved 
`xsl:include`/`xsl:import`/`document()` reference with a `DOMSource` over one 
shared static `Document`. A fresh `DOMSource` was created per call, but 
`DOMSource.getNode()` hands out the same shared `Document`, which escapes to 
the consumer; a component mutating a document it received would surface its 
changes in every later resolution, process-wide.
   
   Following the JDK's XSLTC `TransformerImpl` pattern, the default 
empty-source supplier now builds a fresh empty document per resolution, through 
`SecureDocumentBuilderFactory.newNSInstance(boolean)` — the same secured, 
namespace-aware, JDK-pinned-or-overridden factory selection the `Source` 
rewrite uses, an upgrade over the previous raw 
`DocumentBuilderFactory.newInstance()` lookup (which also ignored 
`overrideDefaultParser`). Creation failure now wraps in `IllegalStateException` 
per call instead of `ExceptionInInitializerError` at class initialization. The 
empty `DOMSource` keeps a null system id, and Saxon's 
`EmptySource.getInstance()` supplier is untouched (a content-less marker with 
no DOM to mutate).
   
   The threat model gains the matching scope rule: exploiting the exposure the 
SpotBugs *expose-internal-representation* patterns warn about presumes an 
adversary already running in the process, a capability the model's adversary 
does not have — so the per-resolution isolation is robustness, not a defended 
boundary, and reports premised on mutating a returned object are `OUT-OF-SCOPE: 
reconfigured`.
   
   Verified with the full surefire matrix and the GraalVM `-Pnative-xalan` 
native suite (the new default supplier passes inside the native image with no 
added reflection metadata); `ShadingFootprintTest` is unchanged, as the 
`SecureDocumentBuilderFactory` classes were already in both pinned closures.
   
   🤖 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]

Reply via email to