[jira] [Created] (OPENNLP-1900) Document and publish the OpenNLP security model

["Richard Zowalla (Jira)" <ji...@apache.org>]

Richard Zowalla created OPENNLP-1900:
----------------------------------------

             Summary: Document and publish the OpenNLP security model
                 Key: OPENNLP-1900
                 URL: https://issues.apache.org/jira/browse/OPENNLP-1900
             Project: OpenNLP
          Issue Type: Documentation
            Reporter: Richard Zowalla
            Assignee: Richard Zowalla


Description:

OpenNLP has no published security model. There is no SECURITY.md in the repository
root or under .github/, and no equivalent section in opennlp-docs. The only written
statement about input trust anywhere in the tree is a javadoc caveat on
SvmDoccatModel.deserialize(), telling callers to invoke it only on trusted streams.

This leaves the central question unanswered: is a model file attacker-controlled
input? Our own record answers it both ways.

  - CVE-2026-42440 (unbounded allocation from a model stream, AbstractModelReader)
    was accepted and fixed.
  - CVE-2026-43825 (unsafe deserialization in SvmDoccatModel) was accepted and fixed.
  - OPENNLP-1891 hardened BaseModel deserialization with an ObjectInputFilter allowlist.
  - OPENNLP-1899 applies the MAX_ENTRIES bound to SymSpellModelSerializer.
  - Yet SvmDoccatModel's javadoc says the opposite: trusted streams only.

In practice we behave as though models should be trusted and we harden the readers
anyway. That position is defensible, but it is undocumented, so every incoming report
in this class has to relitigate it from scratch. It will keep recurring: OpenNLP
deserializes several independent binary formats, and each one is a candidate for the
same finding.

Scope of work:

  1. Write a security model per the ASF guidance at
     https://cwiki.apache.org/confluence/display/SECURITY/Documenting+your+security+model
  2. State explicitly whether model files, training data, and dictionaries are
     considered trusted input, and what we do nonetheless (defence in depth: entry
     bounds, deserialization filters, fail-fast on corrupt headers).
  3. State what is out of scope, so reporters know in advance which findings will be
     treated as hardening rather than vulnerabilities.
  4. Publish as SECURITY.md and cross-reference it from opennlp-docs and the project
     website.
  5. Reconcile the SvmDoccatModel javadoc caveat with whatever position we land on.

Prompted by a report forwarded from ASF Security, which noted the absence of a
published model and pointed at the cwiki guidance.

Two points worth deciding before writing the prose, since they shape the whole docum

- What the actual position is. "Models are trusted, we harden anyway" is the honest ctice, but it needs a committer decision to become policy — it determines whether thenext report in this class gets a CVE or a "thanks, hardened, not a vulnerability."
- Whether this belongs on the 3.x roadmap or is version-independent. A SECURITY.md ces, so it probably shouldn't carry a fix version at all.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)