You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "ppkarwasz (via GitHub)" <gi...@apache.org> on 2026/08/19 10:39:38 UTC
[PR] State the threat-model scope by property contract and exclude transform outputs [commons-xml]
ppkarwasz opened a new pull request, #43:
URL: https://github.com/apache/commons-xml/pull/43
Two threat-model clarifications; documentation only, no code change.
## Scope stated by property contract (f009)
**What is in scope** no longer enumerates "JAXP implementations it recognizes". `XmlFactories` recognizes properties, not implementations: every JAXP implementation is in scope as long as it respects the contract of the features, attributes, and properties the hardening recipes use, and an implementation that cannot accept a required setting makes the factory method throw instead of returning an unhardened factory.
The out-of-scope bullet, the known-non-findings bullet, and the `OUT-OF-SCOPE: foreign implementation` triage row are reworded to the same criterion. This also settles the remark about the StAX path: the StAX floor is installed through the standard `javax.xml.stream.resolver` hook, which the StAX specification requires every implementation to support, so it falls under the same contract with no per-API exception.
## Transform output destinations are out of scope (f010)
New out-of-scope bullet plus a matching known-non-findings bullet: the hardening governs what a parse or transform reads, not where a transform writes. A stylesheet's output-producing instructions (`xsl:result-document` in particular) write wherever the stylesheet directs, within the runtime's permissions; running a stylesheet grants its author that capability, so restricting destinations when the stylesheet is untrusted is the operator's responsibility (an output resolver of the implementation, filesystem permissions, or process sandboxing). Path-traversal or file-write reports through stylesheet output instructions now have an explicit disposition.
## Note
The in-scope bullet is also touched by #38 (Android best-effort wording) and the out-of-scope area by #41 (SAXTransformerFactory surface); whichever lands later reconciles small conflicts, keeping the contract framing together with those changes.
🤖 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: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] State the threat-model scope by property contract and exclude transform outputs [commons-xml]
Posted by "garydgregory (via GitHub)" <gi...@apache.org>.
garydgregory merged PR #43:
URL: https://github.com/apache/commons-xml/pull/43
--
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: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] State the threat-model scope by property contract and exclude transform outputs [commons-xml]
Posted by "garydgregory (via GitHub)" <gi...@apache.org>.
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: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] State the threat-model scope by property contract and exclude transform outputs [commons-xml]
Posted by "ppkarwasz (via GitHub)" <gi...@apache.org>.
ppkarwasz commented on code in PR #43:
URL: https://github.com/apache/commons-xml/pull/43#discussion_r3857068254
##########
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:
Good point: pinned in 5beea39. JAXP 1.4 introduced StaX and the DOM/SAX/TraX resolver hooks, so we need at least this version. Most implementations don't implement JAXP 1.5, so there is no reason to go higher.
Note that some restrictions are mentioned one line below:
```
as long as it respects the contract of the features, attributes, and properties the recipes use.
```
--
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: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] State the threat-model scope by property contract and exclude transform outputs [commons-xml]
Posted by "ppkarwasz (via GitHub)" <gi...@apache.org>.
ppkarwasz commented on code in PR #43:
URL: https://github.com/apache/commons-xml/pull/43#discussion_r3857119583
##########
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:
It wasn't mentioned anywhere else. Now it is, one sentence each: threat model's "Scope and intended use", the site index page, and the `newTransformerFactory` Javadoc (0d499c7).
--
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: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] State the threat-model scope by property contract and exclude transform outputs [commons-xml]
Posted by "ppkarwasz (via GitHub)" <gi...@apache.org>.
ppkarwasz commented on code in PR #43:
URL: https://github.com/apache/commons-xml/pull/43#discussion_r3857068254
##########
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:
Good point — pinned in 5beea39: the sentence now reads "Every implementation of JAXP 1.4 or later is in scope". JAXP 1.4 is the actual baseline the recipes need: the newest platform API they require is StAX (added in 1.4), and the JAXP 1.5 `ACCESS_EXTERNAL_*` properties are deliberately unused (the resolver floors replace them; they appear under **Reserved settings** only as must-not-loosen). The next sentence keeps the claim testable by scoping conformance to the specific features, attributes, and properties each recipe uses, rather than whole-spec conformance.
--
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: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org