garydgregory commented on code in PR #43: URL: https://github.com/apache/commons-xml/pull/43#discussion_r3852943666
########## src/site/markdown/threat_model.md: ########## @@ -230,12 +235,23 @@ and reports against a factory reconfigured in any of the ways below are out of s To parse with your own reader under the hardening guarantees, obtain it from `XmlFactories.newSAXParserFactory()` before wrapping it in a `SAXSource`. -- The behavior of a JAXP implementation that `XmlFactories` does not recognize (it throws rather than returning an - unhardened factory), and any defect in the underlying JAXP implementation itself. +- The behavior of a JAXP implementation that does not respect the contract of the settings a hardening recipe requires + (the factory method throws rather than returning an unhardened factory), + and any defect in the underlying JAXP implementation itself. - **Android, on any API level.** No version of Android supports `FEATURE_SECURE_PROCESSING`, so the hardening there is best-effort and no guarantee is defined (see **Supported runtimes** under [Assumptions about the environment](#assumptions-about-the-environment)). +- **Transform output destinations.** + The hardening governs what a parse or transform reads; + it does not confine what a transform writes. Review Comment: That's an important point that might be worth calling out earlier and in our documentation (website and API) if it's not already mentioned. Is it? ########## src/site/markdown/threat_model.md: ########## @@ -74,7 +74,12 @@ because your reader's settings are indistinguishable from configuration you chos ### What is in scope -- The hardening recipes applied by `XmlFactories` to the JAXP implementations it recognizes (stock JDK, Apache Xerces, Xalan, Saxon, and Woodstox). +- The hardening recipes applied by `XmlFactories`. + Every JAXP implementation is in scope, Review Comment: “Every JAXP implementation is in scope” feels too broad as written. Do we really mean literally any implementation, including ones we don’t know about? If so, it would help to say that the implementations must strictly conform to the JAXP API specification, and to clarify which version of the spec we’re relying on. This makes the requirement more precise and testable. As written, “every implementation” is ambiguous: it could imply an open-ended compatibility claim that’s hard to verify or enforce. Clarifying the spec version also avoids future disagreement about what behavior is expected. -- 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]
