This is an automated email from the ASF dual-hosted git repository.
coheigea pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ws-xmlschema.git
The following commit(s) were added to refs/heads/master by this push:
new 5c95e51b Add draft project security threat-model document (#95)
5c95e51b is described below
commit 5c95e51b6af3df0906d75ea17ea6d78d9ca96346
Author: Jarek Potiuk <[email protected]>
AuthorDate: Thu Jul 9 17:16:25 2026 +0200
Add draft project security threat-model document (#95)
Adds a draft project-level security threat-model document
(draft-THREAT-MODEL.md) at repo root, improving discoverability
for automated security scanners running against this repository.
The file follows the rubric format used by several other ASF
projects piloting security-model discoverability.
The "draft-" prefix signals this is a proposal for the PMC to
review, correct, or reject — not a finalised maintainer-blessed
model. Every claim carries a provenance tag (documented /
inferred / maintainer) so reviewers can see where each claim
originates; §14 collects open questions for the maintainers.
Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>
---
draft-THREAT-MODEL.md | 748 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 748 insertions(+)
diff --git a/draft-THREAT-MODEL.md b/draft-THREAT-MODEL.md
new file mode 100644
index 00000000..ee675a41
--- /dev/null
+++ b/draft-THREAT-MODEL.md
@@ -0,0 +1,748 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+-->
+
+# Apache XMLSchema Security Threat Model (draft)
+
+## §1 Header
+
+- **Project**: Apache XMLSchema — *"a lightweight schema object model
+ that can be used to manipulate and generate XML schema
+ representations"* *(documented: `README.txt`)*.
+- **Repository**: `apache/ws-xmlschema`.
+- **Version / commit**: this model is drafted against the default branch
+ at clone time. A report against project release *N* should be triaged
+ against the model as it stood at *N*, not at HEAD. Latest release
+ documented in `RELEASE-NOTE.txt`: 2.3.0.
+- **Date**: 2026-05-30.
+- **Authors**: ASF Security team draft, awaiting XMLSchema / Webservices
+ PMC review.
+- **Status**: draft — under maintainer review.
+- **Reporting**: vulnerabilities that fall under §8 (claimed
+ properties) should be reported per the Apache Security Team disclosure
+ channel (<https://www.apache.org/security/>); reports that fall under
+ §3 (out of scope) or §9 (properties not provided) will be closed by
+ XMLSchema triagers citing this document. The project does not ship
+ an in-repo `SECURITY.md` at draft time *(inferred — §14 Q1)*.
+- **Provenance legend** —
+ *(documented)* = drawn from in-repo docs / source comments / project
+ website with citation;
+ *(maintainer)* = stated by an XMLSchema maintainer in response to this
+ draft;
+ *(inferred)* = synthesized by the producer from code structure or
+ domain knowledge, awaiting PMC ratification (every *(inferred)* tag has
+ a matching §14 question).
+- **Draft confidence**: 21 documented / 0 maintainer / 24 inferred.
+
+XMLSchema is a Java library that parses, models, walks, and serializes
+W3C XML Schema documents (`.xsd` files). It is *not* a document
+validator at its core (despite the `xmlschema-walker` providing some
+validation helpers): the primary product is the in-memory object model
+of a schema, and the schema-imports / schema-includes resolver that lets
+a `<xs:include>` or `<xs:import>` pull in additional schemas from a
+URI. XMLSchema is consumed primarily by SOAP stacks (Apache CXF, Apache
+Axis) and other code-generation / data-binding tooling. It is bundled
+into runtimes that ingest WSDLs and policy documents.
+
+## §2 Scope and intended use
+
+### Intended use
+
+- In-process parsing and manipulation of W3C XML Schema documents in
+ Java, primarily as part of a tooling pipeline (WSDL import,
+ code generation, data-binding) or as part of a SOAP stack at runtime
+ *(documented: `README.txt`)*.
+- Three modules ship: `xmlschema-core` (the object model + parser +
+ serializer + URI resolver), `xmlschema-walker` (visitor-style schema
+ walking + a `XmlSchemaElementValidator` used for tooling), and
+ `xmlschema-bundle-test` (an OSGi bundle integration test). The
+ `w3c-testcases` directory holds the W3C test suite for regression
+ testing only.
+
+### Deployment shape
+
+XMLSchema is an in-process Java library. There is no daemon, no
+network listener, no CLI. The threat model is therefore that of an
+**XML-parsing library that performs caller-directed network or
+filesystem IO** when it follows `<xs:include>` / `<xs:import>` /
+`schemaLocation` references *(inferred — §14 Q2)*.
+
+### Caller roles
+
+| Role | Trust level | Notes |
+| --- | --- | --- |
+| **Embedding Java application** | trusted | Calls
`XmlSchemaCollection.read(...)`, decides whether the input stream came from
disk, classpath, or wire; decides which `URIResolver` to plug in. |
+| **`URIResolver` implementation** | trusted | Either the bundled
`DefaultURIResolver` (which constructs a `URL` from the parent schema's base
URI + the `schemaLocation` and returns an `InputSource` pointing at it) or a
caller-supplied resolver *(documented:
`xmlschema-core/src/main/java/.../resolver/DefaultURIResolver.java`)*. A
hostile resolver is out of model. |
+| **`ExtensionRegistry` implementation** | trusted | Pluggable via system
property `org.apache.ws.commons.schema.extension_registry` *(documented:
`xmlschema-core/src/main/java/org/apache/ws/commons/schema/XmlSchemaCollection.java`
line 361)*. |
+| **Producer of the schema bytes** (`Reader`, `InputStream`, `InputSource`,
`Source`, `Document`, `Element`) | **variable** — see §6 trust table | The
*only* attacker-controllable input position; in many embeddings the schema
bytes come from a WSDL fetched off the wire. |
+| **Producer of imported / included schemas** (resolved by the `URIResolver`)
| **variable** — typically as untrusted as the parent schema, but can be a
*different* origin if the parent's `<xs:import
schemaLocation="http://attacker/evil.xsd";>` points elsewhere | Following an
`xs:import` is a **second, possibly cross-origin, fetch**. This is the
principal SSRF surface. |
+| **JDK XML platform** (`DocumentBuilderFactory`, `TransformerFactory`,
`SchemaFactory`) | trusted upstream | XMLSchema sets
`FEATURE_SECURE_PROCESSING=true` on the factories it constructs but does
**not** set `disallow-doctype-decl` or unset external-entity properties
explicitly *(documented: `XmlSchemaCollection.java` line 713, `XmlSchema.java`
line 886, `DomBuilderFromSax.java` line 81)*. |
+
+### Component-family table
+
+| Family | Representative entry point | Touches outside the process? |
In-model? |
+| --- | --- | --- | --- |
+| `xmlschema-core` object model — `XmlSchema*` types, `XmlSchemaCollection`,
`SchemaBuilder` | `XmlSchemaCollection.read(InputSource, ...)` and overloads |
**no** for in-memory model; **yes** when the URI resolver follows
`xs:import`/`xs:include` | **yes** |
+| `xmlschema-core` URI resolver — `DefaultURIResolver`,
`CollectionURIResolver`, `URIResolver` |
`XmlSchemaCollection.setSchemaResolver()` | **yes** — by design, fetches
imported schemas | **yes** |
+| `xmlschema-core` serializer — `XmlSchemaSerializer` |
`XmlSchema.write(OutputStream)` | **no** | **yes** |
+| `xmlschema-core` resource loader (internal) — `DocumentBuilderFactory` and
`TransformerFactory` instances configured with `FEATURE_SECURE_PROCESSING=true`
| invoked by `XmlSchemaCollection.read(InputSource, ...)` and
`XmlSchemaSerializer` | **no** | **yes** |
+| `xmlschema-walker` visitor — `XmlSchemaWalker`, `XmlSchemaVisitor`,
`XmlSchemaScope` | walked by a caller-supplied `XmlSchemaVisitor` | **no** |
**yes** |
+| `xmlschema-walker` element validator — `XmlSchemaElementValidator` | walked
at SAX-event time; consults the schema model | **no** (operates on
caller-supplied SAX events) | **yes** |
+| `xmlschema-walker` DOM-from-SAX helper — `DomBuilderFromSax` | builds a DOM
out of SAX events for validator inspection | **no** | **yes** |
+| `xmlschema-bundle-test` | OSGi packaging regression test | n/a | **out of
model** *(§3)* |
+| `w3c-testcases/` | W3C schema test data | n/a | **out of model** *(§3)* |
+
+A finding is in-model only if it reaches a row marked **yes**.
+
+## §3 Out of scope (explicit non-goals)
+
+1. **XML *document* validation against a schema.** XMLSchema is a
+ *schema* model; the only validation-like artifact is
+ `xmlschema-walker`'s `XmlSchemaElementValidator` used in tooling
+ contexts. Findings that depend on the JDK `Validator` /
+ `SchemaFactory` behavior or on third-party validators built on
+ XMLSchema's model are out of model *(inferred — §14 Q3)*. →
+ `OUT-OF-MODEL: out-of-layer`.
+2. **A SOAP / WSDL parser.** XMLSchema parses the *embedded* `<schema>`
+ element of a WSDL, but the WSDL parser itself is upstream (e.g.
+ Apache WSDL4J, Apache CXF). → `OUT-OF-MODEL: out-of-layer`.
+3. **`SchemaFactory` of the JDK.** XMLSchema does not wrap or replace
+ the JDK's `javax.xml.validation.SchemaFactory`. The two are different
+ abstractions *(inferred — §14 Q3)*. → `OUT-OF-MODEL: out-of-layer`.
+4. **`xmlschema-bundle-test` and `w3c-testcases/`.** Integration test
+ harness and W3C regression data. → `OUT-OF-MODEL: unsupported-component`.
+5. **The XML parser bytes-to-DOM step when the caller provides a
+ pre-parsed `Document` / `Element`.** `XmlSchemaCollection.read(Document)`
+ and `.read(Element)` accept a caller-parsed DOM; if the caller's
+ `DocumentBuilderFactory` is not hardened, XMLSchema does not
+ retroactively secure it *(inferred — §14 Q4)*. →
+ `OUT-OF-MODEL: trusted-input`.
+6. **The remote host reached when following an `xs:include` /
+ `xs:import`.** The URI is in the input schema; XMLSchema follows it.
+ What the remote host returns is data XMLSchema then parses, but the
+ *integrity* of the remote host is not WSS4J's concern *(inferred —
+ §14 Q5)*. → `OUT-OF-MODEL: adversary-not-in-scope` for malicious
+ *remote* peer; `VALID` if XMLSchema is tricked into the fetch in the
+ first place by a path the §7 model permits.
+7. **Replacement `URIResolver` / `ExtensionRegistry` implementations.**
+ Caller-pluggable; a hostile resolver is out of model.
+8. **Code shipped in `w3c-testcases/`, `*/src/test/`, `etc/`,
+ `xmlschema-bundle-test/`.** Test data and supporting fixtures.
+ → `OUT-OF-MODEL: unsupported-component`.
+
+## §4 Trust boundaries and data flow
+
+| # | Transition | Authentication | Authorization |
+| --- | --- | --- | --- |
+| B1 | Caller → `XmlSchemaCollection.read(InputSource | InputStream | Reader |
URL | Document | Element)` | none — caller is trusted | none |
+| B2 | `XmlSchemaCollection.read(InputSource, ...)` → JDK `DocumentBuilder`
(with `FEATURE_SECURE_PROCESSING=true`) | none | none |
+| B3 | Schema parser → `URIResolver.resolveEntity(namespace, schemaLocation,
baseUri)` | none | bundled `DefaultURIResolver` does **no host filtering**: it
constructs `new URL(new URL(baseUri), schemaLocation)` and hands back an
`InputSource` pointing at it |
+| B4 | Resolved `InputSource` → `XmlSchemaCollection.read(InputSource, ...)`
(recursive) | none | none |
+| B5 | `XmlSchemaSerializer.serializeSchema(...)` → JDK `TransformerFactory`
(with `FEATURE_SECURE_PROCESSING=true`) | none | none |
+| B6 | `XmlSchemaCollection` ctor →
`System.getProperty("org.apache.ws.commons.schema.extension_registry")` →
`Class.forName()` | none | trusts system properties to be operator-controlled |
+
+### Reachability preconditions per family
+
+- **`xmlschema-core` parser** (`XmlSchemaCollection.read(InputSource)`,
+ `.read(InputStream)`, `.read(Reader)`): in-model when the bytes are
+ attacker-controllable. XMLSchema sets `FEATURE_SECURE_PROCESSING=true`
+ on its internal `DocumentBuilderFactory`, but does **not** explicitly
+ call `setFeature("http://apache.org/xml/features/disallow-doctype-decl";,
+ true)` or `setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES,
+ false)` *(documented: `XmlSchemaCollection.java` line 713)*.
+ `FEATURE_SECURE_PROCESSING` mitigates XML Schema 1.0's most expensive
+ expansion cases on Xerces but does not fully disable DTD processing
+ on every JDK / parser combination *(inferred — §14 Q6)*.
+- **`xmlschema-core` URI resolver** (`DefaultURIResolver`): in-model
+ for SSRF / cross-origin fetch when the input schema is attacker-
+ controlled and contains an `xs:import schemaLocation="…"`. The
+ bundled resolver constructs `new URL(...)` and returns an `InputSource`;
+ the JDK then fetches it on `parse()`.
+- **`xmlschema-core` parser fed a pre-parsed DOM** (`read(Document)`,
+ `read(Element)`): out of model for XXE; the caller's
+ `DocumentBuilderFactory` decided that. In-model for whatever the
+ schema-model semantics imply about the DOM contents.
+- **`xmlschema-walker`**: in-model when the visitor walks an
+ attacker-controlled schema. The walker is purely in-memory.
+- **`XmlSchemaElementValidator` / `DomBuilderFromSax`**: in-model only
+ insofar as they parse SAX events the caller hands in. `DomBuilderFromSax`
+ sets `FEATURE_SECURE_PROCESSING=true` on its
+ `DocumentBuilderFactory` *(documented:
+ `xmlschema-walker/src/main/java/.../docpath/DomBuilderFromSax.java`
+ line 81)*.
+
+## §5 Assumptions about the environment
+
+- **JDK**: minimum Java 17 in the 2.3.0 release; earlier releases
+ supported Java 7 *(documented: `RELEASE-NOTE.txt`)*.
+- **JDK XML platform**: assumes a conformant `DocumentBuilderFactory`,
+ `TransformerFactory`, and SAX parser. The behavior of
+ `FEATURE_SECURE_PROCESSING` depends on the provider in use; XMLSchema
+ does not bundle Xerces *(inferred — §14 Q6)*.
+- **Network**: the bundled `DefaultURIResolver` will issue HTTP / HTTPS
+ / `file://` / `jar:` fetches via the JDK URL handlers when an `xs:include` /
+ `xs:import schemaLocation` is followed. Whether the JVM has a proxy
+ configured, a `SecurityManager`, or any URL-scheme restriction is
+ out of XMLSchema's control *(documented: `DefaultURIResolver.java`)*.
+- **Filesystem**: caller-supplied paths; XMLSchema does no path
+ sanitization of `schemaLocation` values that begin with `file://`
+ *(inferred — §14 Q7)*.
+- **Memory**: schemas are held in memory; XMLSchema has no built-in
+ ceiling on schema-document size, number of imports, or import-graph
+ depth *(inferred — §14 Q8)*.
+- **System properties**: `org.apache.ws.commons.schema.extension_registry`
+ is consulted at `XmlSchemaCollection` construction time, and the
+ named class is loaded via `Class.forName()` *(documented:
+ `XmlSchemaCollection.java` line 361)*. This is a startup-time
+ privilege escalation surface if the system property can be set by
+ an untrusted actor *(inferred — §14 Q9)*.
+- **Wrap in `AccessController.doPrivileged`**: XMLSchema brackets the
+ schema parse and the system-property read in
+ `AccessController.doPrivileged` to be JDK-SecurityManager-compatible
+ on pre-17 JDKs *(documented: `XmlSchemaCollection.java` lines 376,
+ 745)*. On JDK 17+ the SecurityManager is deprecated.
+
+### What XMLSchema does *not* do to its host (negative claims, awaiting
maintainer ratification)
+
+- Opens **no** listening sockets *(inferred — §14 Q10)*.
+- Spawns **no** child processes *(inferred — §14 Q10)*.
+- Installs **no** signal handlers *(inferred — §14 Q10)*.
+- Reads only the documented system property
+ `org.apache.ws.commons.schema.extension_registry` for
+ security-relevant decisions; does **not** consume `LD_*`-style
+ envvars *(inferred — §14 Q10)*.
+- Writes **nothing** to the filesystem of its own initiative; the
+ `XmlSchemaSerializer` writes to the `OutputStream` the caller hands
+ in *(inferred — §14 Q10)*.
+
+## §5a Build-time and configuration variants
+
+XMLSchema is a single Maven artifact set (`xmlschema-core`,
+`xmlschema-walker`, `xmlschema-bundle-test`). There are **no
+compile-time feature toggles** *(inferred — §14 Q11)*. The runtime
+security envelope is shaped by a small set of *runtime extension
+points*:
+
+| Knob | Default | Maintainer stance | Effect |
+| --- | --- | --- | --- |
+| `org.apache.ws.commons.schema.extension_registry` system property | unset
*(documented: `XmlSchemaCollection.java` line 361)* | dev-time customization;
if set by an untrusted actor the named class is loaded into the JVM |
extension-registry class is `Class.forName`-loaded at `XmlSchemaCollection`
ctor time |
+| `XmlSchemaCollection.setSchemaResolver(URIResolver)` | `DefaultURIResolver`
*(documented: `DefaultURIResolver.java`)* | **maintainer ruling required** — is
the documented expectation that production deployments install a *restricted*
resolver that refuses untrusted hosts (proposed: **yes, §10**), or is the
default resolver supported as production-safe? *(inferred — §14 Q12)* |
controls whether `xs:include`/`xs:import` may reach the network |
+| `XmlSchemaCollection.setBaseUri(String)` | unset *(documented)* |
caller-supplied | base URI against which relative `schemaLocation` values
resolve |
+| `DocumentBuilderFactory` provider | JDK default (typically Xerces fork)
*(inferred — §14 Q6)* | depends on the JDK | shape of XML parsing for
`read(InputSource)` / `read(InputStream)` paths |
+
+### The insecure-default case
+
+The bundled `DefaultURIResolver` **does follow remote URLs by default**.
+The maintainer ruling captured in §14 Q12 will determine whether
+"a schema with `<xs:import schemaLocation='http://attacker/'/>` fetched
+the URL during parse" is a `VALID` report (production deployments
+should be protected by the default) or an `OUT-OF-MODEL:
+non-default-build` report (production deployments are *documented* as
+required to install a restricting resolver per §10).
+
+XMLSchema sets `FEATURE_SECURE_PROCESSING=true` on its
+`DocumentBuilderFactory` and `TransformerFactory` instances
+*(documented: `XmlSchemaCollection.java` line 713,
+`XmlSchema.java` line 886)* but does **not** call
+`setFeature("http://apache.org/xml/features/disallow-doctype-decl";,
+true)`. The maintainer ruling on whether XXE / billion-laughs reports
+against a callable `read(InputSource)` are `VALID` (the secure-processing
+feature is the intended defense and is sufficient) or `MODEL-GAP`
+(stricter feature toggles should be set) is captured in §14 Q6.
+
+## §6 Assumptions about inputs
+
+### Per-entry-point trust table
+
+| Entry point | Parameter | Attacker-controllable? | Caller must enforce |
+| --- | --- | --- | --- |
+| `XmlSchemaCollection.read(InputSource is)` | `is` bytes | **yes** | nothing
— XMLSchema sets `FEATURE_SECURE_PROCESSING=true` on its
`DocumentBuilderFactory`; caller may need to install a restricting
`URIResolver` if the source contains untrusted `xs:include`/`xs:import` |
+| `XmlSchemaCollection.read(InputStream in)` | `in` bytes | **yes** | same as
above |
+| `XmlSchemaCollection.read(Reader r)` | `r` characters | **yes** | same as
above |
+| `XmlSchemaCollection.read(URL url)` | `url` | caller-supplied | caller
controls; XMLSchema fetches via JDK URL handlers |
+| `XmlSchemaCollection.read(Document doc)` | `doc` | **yes if doc was parsed
from untrusted bytes** | caller's `DocumentBuilderFactory` is responsible for
XXE / DTD posture; XMLSchema does not re-parse |
+| `XmlSchemaCollection.read(Element el)` | `el` | same as `read(Document)` |
same as above |
+| `XmlSchemaCollection.setSchemaResolver(URIResolver)` | resolver |
caller-supplied | replacing the default is the documented path for production
hardening *(inferred — §14 Q12)* |
+| `XmlSchemaCollection.setBaseUri(String)` | `baseUri` | **caller-supplied
trusted string** | not validated; if attacker can set this they can pivot the
import-resolver origin |
+| `XmlSchemaCollection.setExtReg(ExtensionRegistry)` | registry |
caller-supplied | caller's choice |
+| `XmlSchema.write(OutputStream)` / `XmlSchema.write(Writer)` | output sink |
caller-supplied | caller's choice; `FEATURE_SECURE_PROCESSING=true` is set on
the internal `TransformerFactory` *(documented: `XmlSchema.java` line 886)* |
+| `XmlSchemaWalker.walk(XmlSchemaElement)` | walked schema | as untrusted as
the schema | none — pure in-memory walking |
+| `XmlSchemaElementValidator` (walker module) | SAX events + schema model | as
untrusted as both | caller validates / sanitizes outside |
+| `DomBuilderFromSax` | SAX events | as untrusted as the source of the events
| `FEATURE_SECURE_PROCESSING=true` is set *(documented:
`DomBuilderFromSax.java` line 81)* |
+| System property `org.apache.ws.commons.schema.extension_registry` | class
name | **trusted by §3 item 7** | operator must lock down property setting in
shared-JVM deployments |
+
+### Size / shape / rate
+
+- No documented limit on schema-document size *(inferred — §14 Q8)*.
+- No documented limit on the import-graph depth or breadth
+ *(inferred — §14 Q8)*.
+- No rate limit on URL fetches when following `xs:import`
+ *(inferred — §14 Q12)*.
+
+## §7 Adversary model
+
+### Actors
+
+| Actor | In scope? | Capabilities |
+| --- | --- | --- |
+| **Producer of the input schema bytes** | **yes** | full byte control of the
schema; can include `<xs:import schemaLocation="…"/>` pointing anywhere |
+| **Producer of an imported schema** at a URL the parent schema references |
**yes** | returns a malicious downstream `.xsd` after the parent triggers the
fetch |
+| **Network attacker on the path between XMLSchema and an HTTP
`schemaLocation`** | **partial** *(inferred — §14 Q13)* — TLS is the JDK URL
handler's concern; XMLSchema does no certificate pinning; if the operator
allowed plain `http://` fetches a network attacker can substitute |
+| **In-process callers (the embedding application)** | **out of scope** |
trivially full control |
+| **Owner of the host filesystem** | **out of scope** | by construction |
+| **Author of a hostile `URIResolver` / `ExtensionRegistry`** | **out of
scope** *(§3 item 7)* |
+| **Author of system-property setting on JVM startup** | **out of scope** if
operator-controlled; in scope only when an untrusted actor can set
`org.apache.ws.commons.schema.extension_registry` *(inferred — §14 Q9)* |
+| **Co-tenant on the same JVM** (multi-app servlet container) | **out of
scope** *(inferred — §14 Q14)* |
+| **Side-channel observer** | **out of scope** *(inferred — §14 Q14)* |
+| **Quantum adversary** | **out of scope** |
+
+## §8 Security properties the project provides
+
+### P1 — Memory-safety on the schema parse, given a JDK conformant to §5
+
+- **Condition**: bytes arrive through one of the `read(...)` paths; the
+ JDK platform supplies a working `DocumentBuilder`; XMLSchema sets
+ `FEATURE_SECURE_PROCESSING=true` on its factories.
+- **Violation symptom**: a crafted `.xsd` causes XMLSchema's *own*
+ code (not the JDK XML parser) to throw an unhandled exception that
+ is **not** a `XmlSchemaException` / `ParserConfigurationException` /
+ `IOException` / `SAXException` — i.e. crashes outside the documented
+ failure mode. Memory corruption is JVM-level and not a Java-side
+ defect.
+- **Severity**: typically **correctness-only** (Java does not have
+ memory corruption); `VALID-HARDENING` if the symptom is an
+ unhandled `RuntimeException` that the caller cannot catch through
+ the documented surface *(inferred — §14 Q15)*.
+- *(inferred — §14 Q15)*
+
+### P2 — Some mitigation of "expensive" schema expansion via
`FEATURE_SECURE_PROCESSING=true` on the internal `DocumentBuilderFactory` and
`TransformerFactory`
+
+- **Condition**: the JDK XML provider honors `FEATURE_SECURE_PROCESSING`;
+ XMLSchema's `read(InputSource | InputStream | Reader)` paths take the
+ internal `DocumentBuilderFactory`.
+- **Violation symptom**: a billion-laughs / quadratic-expansion attack
+ parses to completion (no `SAXException`, no `XmlSchemaException`),
+ the host JVM runs out of memory or pegs the CPU.
+- **Severity**: **maintainer ruling required** — see §14 Q6.
+- *(documented: `XmlSchemaCollection.java` line 713,
+ `XmlSchema.java` line 886, `DomBuilderFromSax.java` line 81)*
+
+### P3 — Round-trip parse → model → serialize consistency
+
+- **Condition**: a well-formed schema is parsed and serialized; the
+ serializer's `TransformerFactory` is configured with
+ `FEATURE_SECURE_PROCESSING=true`.
+- **Violation symptom**: a serialized schema is not a valid XSD, or
+ differs semantically from the parsed one *(inferred — §14 Q16)*.
+- **Severity**: **correctness-only**; not security-relevant unless the
+ divergence creates a security-meaningful misinterpretation downstream
+ *(inferred — §14 Q16)*.
+- *(inferred — §14 Q16)*
+
+### P4 — `xmlschema-walker` deterministic visit order
+
+- **Condition**: visitor pattern is invoked on the in-memory model.
+- **Violation symptom**: visit order varies across invocations on the
+ same model, breaking caller assumptions.
+- **Severity**: **correctness-only**.
+- *(inferred — §14 Q17)*
+
+## §9 Security properties the project does *not* provide
+
+State each plainly so a triager can route an inbound report to the
+matching disclaimer.
+
+- **No SSRF defense on `xs:import`/`xs:include schemaLocation` URLs.**
+ The bundled `DefaultURIResolver` constructs a `URL` from the parent
+ schema's base URI plus the schema-location value and returns an
+ `InputSource` pointing at it. The JDK then fetches it on parse.
+ XMLSchema applies *no* allowlist, *no* protocol restriction, and *no*
+ host filtering of any kind. The caller is responsible for installing
+ a restricting `URIResolver` if the input schema is attacker-controlled
+ *(documented: `DefaultURIResolver.java`)*.
+- **No XXE / DTD defense beyond `FEATURE_SECURE_PROCESSING=true`.**
+ XMLSchema does **not** call
+ `setFeature("http://apache.org/xml/features/disallow-doctype-decl";,
+ true)`, does **not** set
+ `setFeature("http://xml.org/sax/features/external-general-entities";,
+ false)`, and does **not** unset the analogous `XMLInputFactory`
+ properties. Whether this is sufficient depends on the JDK XML
+ provider in use *(inferred — §14 Q6)*.
+- **No defense when the caller passes in a pre-parsed `Document` or
+ `Element`.** The hardening on the internal `DocumentBuilderFactory`
+ is moot — the caller's parser produced the DOM *(documented:
+ `XmlSchemaCollection.read(Document)` / `.read(Element)`)*.
+- **No bound on schema-document size, import-graph depth, or import
+ fan-out.** A schema that includes thousands of imports, or imports
+ recursively, will be processed to completion or until JVM resources
+ are exhausted *(inferred — §14 Q8)*.
+- **No protection of imported schemas at rest.** Schemas pulled from
+ HTTP are fetched in cleartext if the URL is `http://`. The caller
+ must use TLS-protected URLs or install a restricting resolver
+ *(documented: `DefaultURIResolver.java`)*.
+- **No defense against the system-property-controlled
+ `ExtensionRegistry` being a malicious class.** The named class is
+ loaded into the running JVM and instantiated.
+- **No data-at-rest protection.** Schemas serialized by
+ `XmlSchemaSerializer` are plain XML on whatever sink the caller
+ provided.
+- **No constant-time guarantees.** XMLSchema does not deal with
+ secrets.
+- **No defense against side-channel observation.**
+- **No quantum resistance.**
+
+### False-friend properties (call out separately)
+
+- **`FEATURE_SECURE_PROCESSING=true` looks like full XXE defense,
+ but it is not.** On many JDK XML providers it imposes safe limits on
+ entity expansion (XML-1.0 quadratic-blow-up bounds) but does **not**
+ disable external entities or DTD processing entirely. Strict XXE
+ defense in Java requires the explicit
+ `setFeature("http://apache.org/xml/features/disallow-doctype-decl";,
+ true)` plus
`setFeature("http://xml.org/sax/features/external-general-entities";,
+ false)` and
`setFeature("http://xml.org/sax/features/external-parameter-entities";,
+ false)`. XMLSchema does the *FEATURE_SECURE_PROCESSING* hardening
+ but not the explicit XXE flags *(inferred — §14 Q6)*.
+- **`DefaultURIResolver` looks like a sandbox, but it isn't.** It is
+ the *bundled* resolver; its job is to resolve `xs:include`/`xs:import`,
+ not to filter destinations.
+- **`XmlSchemaCollection.setBaseUri(String)` looks like a chroot for
+ imports, but it isn't.** If the importing schema sets an absolute
+ URL in `schemaLocation`, the base URI is irrelevant — the absolute
+ URL wins *(inferred — §14 Q18)*.
+- **`xmlschema-walker.XmlSchemaElementValidator` looks like a
+ document validator, but it is a tooling helper.** It is not a
+ drop-in replacement for `javax.xml.validation.Validator` and does
+ not promise XSD-1.0 / 1.1 conformance *(inferred — §14 Q3)*.
+
+### Well-known attack classes XMLSchema does not single-handedly defend against
+
+- **XXE / external-entity disclosure** via DTD-enabled JDK XML
+ providers — depends on the JDK XML factory and on caller-side
+ hardening when `read(Document)` / `read(Element)` is used.
+- **SSRF via `xs:import schemaLocation`** — see §9 first bullet.
+- **Billion-laughs / quadratic blowup** — partially mitigated by
+ `FEATURE_SECURE_PROCESSING=true`, but not universally.
+- **Schema-amplification DoS** — a deeply nested or heavily-recursive
+ schema can exhaust memory.
+- **Confused-deputy fetch via untrusted `baseUri` + relative
+ `schemaLocation`** — the operator-supplied base URI is trusted.
+
+## §10 Downstream responsibilities
+
+The embedding Java application **must**:
+
+1. Decide whether the schema bytes being parsed are
+ attacker-controllable. If yes, install a restricting
+ `URIResolver` via `XmlSchemaCollection.setSchemaResolver(...)` that
+ refuses arbitrary `http://` / `https://` / `file://` / `jar:` /
+ `ftp:` URLs. The bundled `DefaultURIResolver` does not filter
+ *(documented: `DefaultURIResolver.java`)*.
+2. When passing a pre-parsed `Document` / `Element` into
+ `XmlSchemaCollection.read(...)`, use a `DocumentBuilderFactory`
+ hardened against XXE — specifically with `disallow-doctype-decl=true`
+ and external-entity processing disabled.
+3. When using the `read(InputSource | InputStream | Reader)` path
+ against attacker-controlled bytes, verify the JDK XML provider in
+ use treats `FEATURE_SECURE_PROCESSING=true` as sufficient defense
+ *(inferred — §14 Q6)*.
+4. Bound the maximum allowable schema size and the maximum import-graph
+ depth at the *caller* level. XMLSchema imposes no such limit
+ *(inferred — §14 Q8)*.
+5. Set `org.apache.ws.commons.schema.extension_registry` only at JVM
+ startup from a trusted source; do not allow untrusted actors to set
+ it.
+6. Set `XmlSchemaCollection.setBaseUri(...)` from an operator-trusted
+ string, not from anywhere an attacker can influence.
+7. Run on a release-supported branch (currently 2.3.0 line)
+ *(documented: `RELEASE-NOTE.txt`)*.
+
+## §11 Known misuse patterns
+
+- **Passing an attacker-controlled `.xsd` to
+ `XmlSchemaCollection.read(InputSource)` with the
+ `DefaultURIResolver` in place.** The schema's `xs:include` /
+ `xs:import` are followed unrestricted, leading to SSRF / cross-origin
+ fetch / `file://` disclosure *(documented:
+ `DefaultURIResolver.java`)*. The fix is per §10 item 1.
+- **Trusting `read(Document)` / `read(Element)` to inherit XXE
+ defenses from XMLSchema.** XMLSchema does not re-parse; the caller's
+ factory chose the posture.
+- **Setting `org.apache.ws.commons.schema.extension_registry` from a
+ servlet-context init parameter or a config file an end user can
+ influence.** The named class is loaded and instantiated at
+ `XmlSchemaCollection` construction.
+- **Treating `XmlSchemaElementValidator` (walker module) as a
+ conformant XSD validator.** It is a tooling helper; conformant
+ document validation against an XSD requires the JDK
+ `javax.xml.validation.Validator` *(inferred — §14 Q3)*.
+- **Using the same `XmlSchemaCollection` instance across thread
+ boundaries without external synchronization.** XMLSchema does not
+ document its threading model *(inferred — §14 Q19)*.
+- **Fetching imported schemas over plain `http://` from a remote
+ registry.** The operator should restrict to `https://` or pin to a
+ trusted mirror.
+- **Letting the parsed schema's base URI be derived from the
+ attacker-controlled bytes** (e.g. an absolute `xmlns:tns` URL the
+ attacker provided) and then walking the URI graph from that base.
+
+## §11a Known non-findings (recurring false positives)
+
+This section is the highest-leverage input for automated agentic
+security scans. Each entry: tool symptom, why it is safe under the
+model, the section that licenses the call.
+
+- **"`new URL(baseUri, schemaLocation).openConnection()` — SSRF risk in
+ `DefaultURIResolver`."** Bundled behavior, explicitly documented as
+ defaulted unrestricted; operator must install a restricting resolver
+ per §10 item 1. → `OUT-OF-MODEL: trusted-input` *(if the maintainer
+ rules at Q12 that the default is dev/test)*, or `VALID-HARDENING`
+ *(if the maintainer rules the default is supported)*.
+- **"`DocumentBuilderFactory.newInstance()` not setting
+ `disallow-doctype-decl`."** Investigated under §14 Q6 — XMLSchema
+ *does* set `FEATURE_SECURE_PROCESSING=true` which is the
+ XSLT-conventional hardening lever. → `KNOWN-NON-FINDING` if the Q6
+ ruling lands "secure-processing is sufficient", else `VALID-HARDENING`.
+- **"`Class.forName(System.getProperty(...))` is dynamic-class-loading."**
+ Documented extension point; the system property is the trust gate
+ *(documented: `XmlSchemaCollection.java` line 361)*. → `OUT-OF-MODEL:
+ trusted-input`.
+- **"`AccessController.doPrivileged` deprecated in JDK 17."** JDK
+ compatibility wrapper; deprecation is informational on JDK 17 and
+ required on pre-17 JDKs. → `KNOWN-NON-FINDING`.
+- **"Hardcoded password in test resources."** No such resource exists
+ in this repo; if a tool flags `w3c-testcases/` data, it is W3C
+ conformance suite data *(documented: top-level `w3c-testcases/`)*. →
+ `OUT-OF-MODEL: unsupported-component`.
+- **"`XmlSchemaSerializer` uses identity Transformer — could be
+ exploited via XSLT injection."** Identity transform; no stylesheet
+ reachable from input *(documented: `XmlSchema.java` line 886)*. →
+ `KNOWN-NON-FINDING`.
+- **"`URLConnection.getInputStream()` without timeout."** True;
+ XMLSchema does no read-timeout on fetched imports
+ *(inferred — §14 Q12)*. → `VALID-HARDENING` if Q12 rules the
+ default-resolver is production-safe; otherwise documented as a §10
+ responsibility.
+- **"Path traversal via `XmlSchemaCollection.setBaseUri()`."** Caller-
+ supplied trusted string per §6. → `OUT-OF-MODEL: trusted-input`.
+- **"Schemas in `w3c-testcases/` contain wide-open DTDs."** W3C
+ conformance suite, used as input to unit tests *(documented:
+ top-level `w3c-testcases/`)*. → `OUT-OF-MODEL: unsupported-component`.
+- **"`ExtensionRegistry` is `Class.forName`-loaded — RCE."** Trusted
+ system property per §3 item 7. → `OUT-OF-MODEL: trusted-input`.
+- **"`XmlSchemaCollection.read(URL)` follows `file://` to read
+ arbitrary local files."** Caller passed the URL; trusted entry point.
+ → `OUT-OF-MODEL: trusted-input`.
+
+## §12 Conditions that would change this model
+
+Revise this document when any of the following lands:
+
+- A change in the default `URIResolver` behavior — e.g. adding host
+ filtering, refusing non-HTTPS, or adding read/connect timeouts.
+- A change in the default `FEATURE_SECURE_PROCESSING=true` hardening —
+ e.g. adding explicit `disallow-doctype-decl=true`.
+- A new public entry point on `XmlSchemaCollection` that accepts new
+ input shapes.
+- A new built-in resource limit on schema size or import-graph depth.
+- A new feature flag in `xmlschema-walker`'s validator that turns it
+ into a claimed-conformant document validator.
+- An upgrade of the supported JDK minimum that changes the JDK XML
+ provider behavior.
+- A change in the system-property contract for `ExtensionRegistry`.
+- A vulnerability report that cannot be cleanly routed to one of the
+ §13 dispositions — evidence the model has a gap.
+
+## §13 Triage dispositions
+
+A report against XMLSchema receives exactly one of the following:
+
+| Disposition | Meaning | Licensed by |
+| --- | --- | --- |
+| `VALID` | Violates a §8 property via an in-scope §7 adversary using an
in-scope §6 input. | §8, §6, §7 |
+| `VALID-HARDENING` | No §8 property violated, but a §11 misuse pattern can be
made harder to fall into by code change. Typically no CVE. | §11 |
+| `OUT-OF-MODEL: trusted-input` | Requires attacker control of a §6 parameter
the model marks trusted (caller-supplied `Document` / `Element`,
caller-supplied `baseUri`, caller-supplied `URIResolver`, JVM system property,
etc.). | §6 |
+| `OUT-OF-MODEL: adversary-not-in-scope` | Requires a §7 actor the model
excludes (in-process caller, hostile `URIResolver`, operator). | §7 |
+| `OUT-OF-MODEL: unsupported-component` | Lands in `w3c-testcases/`,
`*/src/test/`, `etc/`, `xmlschema-bundle-test/`. | §3 items 4, 8 |
+| `OUT-OF-MODEL: non-default-build` | Only manifests under a §5a configuration
the maintainer rules dev/test (e.g. an unsafe custom `URIResolver`). | §5a |
+| `OUT-OF-MODEL: out-of-layer` | Concerns a *document* validation step
delegated to `javax.xml.validation.Validator`, or a WSDL parser upstream. | §3
items 1–3 |
+| `BY-DESIGN: property-disclaimed` | Concerns a §9 property the project
explicitly does not provide (no SSRF defense, no XXE defense beyond
secure-processing, no resource ceiling). | §9 |
+| `KNOWN-NON-FINDING` | Matches a §11a recurring false positive. | §11a |
+| `MODEL-GAP` | Cannot be cleanly routed to any of the above — triggers §12
model revision. | §12 |
+
+## §14 Open questions for the maintainers
+
+Every *(inferred)* tag in the body maps to one of these. Proposed
+answers are inline; please confirm, correct, or strike.
+
+### Wave 1 — security policy + meta
+
+**Q1.** XMLSchema does not currently ship an in-repo `SECURITY.md`.
+The de facto policy is "report via `https://www.apache.org/security/`";.
+Should the project (a) adopt a `SECURITY.md` that names a supported-
+branch matrix (proposed), (b) leave reporting to the foundation page
+only, or (c) defer to the Webservices PMC's umbrella policy? *(meta)*
+
+**Q2.** Confirm that XMLSchema's threat model treats the project as
+**a schema-modeling library that performs network IO when resolving
+imports**, not a generic XML parser (proposed: **yes**). *(maps to §2)*
+
+**Q3.** `xmlschema-walker.XmlSchemaElementValidator` — proposed
+position is "tooling helper, not a claimed-conformant document
+validator". Confirm? *(maps to §3 item 1, §9 false-friend, §11)*
+
+### Wave 2 — XXE / DTD posture (highest leverage)
+
+**Q4.** When `read(Document)` / `read(Element)` is the entry point,
+proposed position is "the caller's DOM was already parsed; XMLSchema
+makes no XXE claim about it" (`OUT-OF-MODEL: trusted-input`). Confirm?
+*(maps to §3 item 5, §13)*
+
+**Q5.** When the URI resolver follows an `xs:import schemaLocation`,
+proposed position is "what the remote host returns is parsed by the
+*caller-installed* parser path; the *fetch* itself is the
+attacker-influenced action and §9 disclaims SSRF defense" (`§9`).
+Confirm? *(maps to §3 item 6, §9)*
+
+**Q6.** **The big XXE question.** XMLSchema sets
+`FEATURE_SECURE_PROCESSING=true` on its internal
+`DocumentBuilderFactory` and `TransformerFactory`. It does **not** set
+`disallow-doctype-decl=true`, `external-general-entities=false`, or
+`external-parameter-entities=false`. The maintainer ruling is required
+on:
+
+- (a) Is `FEATURE_SECURE_PROCESSING=true` considered the sufficient
+ defense (so XXE reports against
+ `XmlSchemaCollection.read(InputSource)` are `KNOWN-NON-FINDING`)?
+- (b) Or are explicit `disallow-doctype-decl=true` and external-entity
+ toggles the supported posture, with the current state being a
+ `VALID-HARDENING` to be addressed?
+
+Proposed answer: **(b), with a future-PR to add the explicit toggles
+and document `FEATURE_SECURE_PROCESSING=true` as the present
+inheritance from JDK Xerces.** *(maps to §5a, §8 P2, §9, §11a)*
+
+### Wave 3 — URI resolver / SSRF
+
+**Q7.** Confirm that XMLSchema does *not* sanitize `schemaLocation`
+when it begins with `file://`, `jar:`, etc. (proposed: no sanitization;
+operator's `URIResolver` is the gate). *(maps to §5, §11a)*
+
+**Q8.** No documented bound on schema-document size or
+import-graph depth (proposed: confirm "no bound, operator's
+responsibility to cap"). Are there *de facto* bounds inside XMLSchema?
+*(maps to §5, §9, §10 item 4)*
+
+**Q9.** `org.apache.ws.commons.schema.extension_registry` system
+property: confirm that production deployments are expected to set
+it (if at all) at JVM startup from a trusted source — i.e. an
+untrusted-actor-set value is `OUT-OF-MODEL: trusted-input` (proposed).
+*(maps to §5a, §11)*
+
+**Q10.** Negative-side inventory in §5: XMLSchema opens **no**
+sockets *other than what the JDK URL handler does when following an
+import*; spawns **no** processes; installs **no** signal handlers;
+reads **only** the documented system property; writes **nothing** of
+its own initiative. Confirm? *(maps to §5)*
+
+**Q11.** Build-time variants: confirm there are no compile-time feature
+toggles; the security envelope is shaped only by runtime extension
+points (proposed). *(maps to §5a)*
+
+**Q12.** **The big URI-resolver question.** The bundled
+`DefaultURIResolver` follows `http://` / `https://` / `file://` /
+`jar:` URLs without filtering. Is this:
+
+- (a) "Supported production posture" — a report that an attacker
+ schema's `<xs:import schemaLocation='http://attacker/'/>` triggered
+ a fetch is `VALID`?
+- (b) "Dev/test default; operators are documented as required to
+ install a restricting resolver per §10" — same report is
+ `OUT-OF-MODEL: non-default-build`?
+
+Proposed: **(b)** with a clarification in `README.txt` and/or
+`SECURITY.md` that production deployments handling untrusted schema
+bytes must install a restricting `URIResolver`. *(maps to §5a, §9,
+§10 item 1, §11a, §13)*
+
+### Wave 4 — adversary model, edge cases
+
+**Q13.** Network attacker on `http://` import fetches: proposed
+position is "operator is documented as required to use `https://`
+or a restricting resolver; TLS validity is the JDK URL handler's
+concern". Confirm? *(maps to §7)*
+
+**Q14.** Co-tenant in shared JVM and side-channel observers: out of
+scope (proposed)? *(maps to §7)*
+
+**Q15.** §8 P1 (memory safety on parse): proposed wording "any
+`RuntimeException` outside the documented `XmlSchemaException`/
+`ParserConfigurationException`/`IOException`/`SAXException` family is
+`VALID-HARDENING`". Confirm? *(maps to §8 P1)*
+
+**Q16.** §8 P3 (round-trip parse → model → serialize consistency):
+do you claim this as a security property, or only as a correctness
+one? Proposed: correctness-only unless the divergence creates a
+security-meaningful downstream misinterpretation, in which case it is
+a `VALID-HARDENING`. *(maps to §8 P3)*
+
+**Q17.** §8 P4 (walker deterministic visit order): is the visit order
+documented? Proposed: correctness-only. *(maps to §8 P4)*
+
+**Q18.** `setBaseUri(...)` semantics: if an `<xs:import
+schemaLocation='http://absolute/'/>` is encountered, the base URI is
+ignored. Confirm? *(maps to §9 false-friend)*
+
+**Q19.** Threading model: is `XmlSchemaCollection` documented as
+thread-safe? Proposed: not thread-safe; callers synchronize. *(maps to
+§11)*
+
+### Wave 5 — coexistence & publication
+
+**Q20.** This document should be hosted in-repo at
+`docs/security/threat-model.md` (proposed) or on
+`ws.apache.org/xmlschema/`? *(meta)*
+
+**Q21.** §11a known-non-findings is thin (~11 patterns). Could the
+XMLSchema PMC populate from the JIRA "not a bug" / "wontfix"
+closures (`XMLSCHEMA-*` tickets)? Concrete asks: 3–5 patterns the PMC
+sees recur in inbound reports. *(meta — §11a)*
+
+**Q22.** What kind of change to XMLSchema should trigger a revision
+(proposed list in §12 — confirm or correct)? *(meta — §12)*
+
+---
+
+## Appendix: SECURITY.md / website → §x back-map
+
+XMLSchema does not ship a `SECURITY.md`. The threat-model sources are
+the in-repo `README.txt`, the `RELEASE-NOTE.txt`, and the JavaDoc /
+source comments. The project website is
+<https://ws.apache.org/xmlschema/>.
+
+| Source | Claim | Lands in |
+| --- | --- | --- |
+| `README.txt` | "lightweight schema object model that can be used to
manipulate and generate XML schema representations" | §1, §2 intended use |
+| `RELEASE-NOTE.txt` (2.3.0) | Java 17 minimum, Java 7 dropped | §5
environment |
+|
`xmlschema-core/src/main/java/org/apache/ws/commons/schema/XmlSchemaCollection.java`
line 361 | `org.apache.ws.commons.schema.extension_registry` system property
loaded via `Class.forName` | §5a, §6, §11 |
+| `XmlSchemaCollection.java` line 713 |
`docFac.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, TRUE)` | §5a, §8 P2 |
+| `XmlSchemaCollection.java` line 745 | `AccessController.doPrivileged`
wrapper for the SAX parse | §5 |
+| `XmlSchema.java` line 886 |
`trFac.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, TRUE)` for serializer
| §5a, §8 P2 |
+| `xmlschema-core/src/main/java/.../resolver/DefaultURIResolver.java` | URL
composed from `baseUri` + `schemaLocation`; no filtering | §3 item 7, §9 SSRF
disclaim, §10 item 1, §11 first bullet |
+| `xmlschema-core/src/main/java/.../resolver/URIResolver.java` | Resolver
interface — caller-pluggable | §2 caller-roles, §10 item 1 |
+| `xmlschema-walker/src/main/java/.../docpath/DomBuilderFromSax.java` line 81
| `factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, TRUE)` | §5a, §8
P2 |
