ppkarwasz commented on PR #18: URL: https://github.com/apache/commons-xml/pull/18#issuecomment-4915834717
> can you configure your editor to avoid making whitespace changes in unrelated files and remove them from this PR? If you are referring to the EOL and British spelling, I couldn't resist the urge to fix them in the whole library, but I reverted those changes. > I'm not super-concerned about this issue. If the caller calls set*Resolver that's their decision. They've chosen to install what they've chosen to install. Increasingly this all feels like leaky band-aids on top of band-aids. A more fundamental approach might be called for that operates much lower in the stack. What approach do you propose? Since the hardening for Xerces used resolvers, this looked like a cheap feature to introduce. In [COMMONSXML-2](https://issues.apache.org/jira/browse/COMMONSXML-2) I plan to remove the code that sets expansion limits uniformly, since this is useful for testing, but hardly needed in practice. For [COMMONSXML-4](https://issues.apache.org/jira/browse/COMMONSXML-4) I was thinking about ignoring external fetches universally (not only for the external subset). With the two changes above the hardening of `DocumentBuilderFactory` would look like: ```java // Android exposes no FSP, ACCESS_EXTERNAL_* or attribute API, and KXmlParser drops user-defined entities; nothing to apply. if (ANDROID_DOCUMENT_BUILDER_FACTORY.equals(factory.getClass().getName())) { return factory; } // Required: enables the implementation's security manager, which carries the limits. setFeature(factory, XMLConstants.FEATURE_SECURE_PROCESSING, true); // Required: install an ignore-alll resolver on every DocumentBuilder. return new HardeningDocumentBuilderFactory(factory, Resolvers.IgnoreAll.ENTITY2); ``` -- 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]
