Harden XML parsing via commons-xml

[ppkarwasz]

Replaces all direct JAXP factory instantiations (DocumentBuilderFactory, SAXParserFactory, TransformerFactory) with the secure factories from org.apache.commons: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 and CodeQL builds with -Puse-apache-snapshots (inherited from the org.apache:apache parent POM) so the SNAPSHOT resolves; CodeQL's autobuild receives the profile through MAVEN_ARGS.
• 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 lifts the accessExternalSchema restriction to keep resolver-based schema validation (such as via CatalogResolver) working under secure processing: due to a JDK bug, schema documents supplied by an entity resolver are not marked as resolver-created (old JDK 8 versions never mark them; newer versions fail to mark only those supplied by an EntityResolver2), so the check would refuse them. Lifting the restriction does not reopen external fetches: the parser never retrieves a schema itself, because the secure factory's resolver floor resolves every lookup the caller's resolver leaves unresolved to empty content instead of fetching it.
• 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); the affected test classes also pass on Java 8, where the JDK applies the accessExternalSchema check even to resolver-supplied schema documents.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NS6CoaDG2mfSNpy4Ukhvrn