ppkarwasz opened a new pull request, #647: URL: https://github.com/apache/commons-configuration/pull/647
Replaces all direct JAXP factory instantiations (`DocumentBuilderFactory`, `SAXParserFactory`, `TransformerFactory`) with the secure factories from [`org.apache.commons:commons-xml`](https://github.com/apache/commons-xml). These enable `FEATURE_SECURE_PROCESSING` and install a non-removable entity-resolver floor on every parser they produce: external DTD, entity, schema and XInclude lookups that a caller-set resolver does not resolve are resolved to empty content instead of being fetched, and internal entity expansion is bounded, regardless of the JAXP implementation on the classpath. Hardening the parsing of a configuration file is admittedly not necessary: configuration files are normally trusted. This limits the side-effects if a user (against advice) decides to parse untrusted configuration files. ### Changes - Add the `commons-xml` dependency (`1.0.0-SNAPSHOT` until its first release) and run the CI build with `-Puse-apache-snapshots` (inherited from the `org.apache:apache` parent POM) so the SNAPSHOT resolves. - Route factory creation through `SecureDocumentBuilderFactory`, `SecureSAXParserFactory` and `SecureTransformerFactory` in `XMLConfiguration`, `XMLDocumentHelper`, `XMLPropertiesConfiguration` and `XMLPropertyListConfiguration`, plus the affected tests. Transformers created by `SecureTransformerFactory` rewrite their sources on every `transform` call, so no explicit hardening of the source passed to `XMLDocumentHelper.transform` is needed. - `XMLConfiguration` keeps its `DefaultEntityResolver` contract (return `null` for unknown entities): a `null` return no longer lets the parser fetch the external resource, because the resolver floor resolves it to empty content instead. - When schema validation is enabled, `XMLConfiguration` disables `EntityResolver2` handling (`http://xml.org/sax/features/use-entity-resolver2`): due to a JDK bug, schema documents supplied by an `EntityResolver2` are not marked as resolver-created, so the `accessExternalSchema` check enabled by secure processing refuses them even when a caller-set resolver (such as `CatalogResolver`) resolves them locally. The plain `EntityResolver` path marks them correctly and keeps resolver-based schema validation working. - `TestMultiFileConfigurationBuilder#testSchemaValidationError` registers the local test schema for its absolute `https` system URI via an XML catalog, since the hardened parser no longer fetches it; the test now reaches the intended schema validation error again. Full test suite passes with `-Puse-apache-snapshots` (3051 tests). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01NS6CoaDG2mfSNpy4Ukhvrn -- 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]
