Skip to content

Prerelease Considerations

npond edited this page Aug 24, 2026 · 6 revisions

Prerelease Considerations

⚠️ n8PDF is in alpha testing. Do not use it in production. It has never shipped a release, and nobody has run it in anger.

What "alpha" means here

The library builds, the suite passes, and the fidelity numbers on Matching Word are real — but none of that adds up to production readiness yet:

  • It has never shipped. There is no published NuGet package (#61), no released version, and therefore no version anybody has run in anger. The API surface (The API) is intended to be stable, but until a v1.0.0 tag is cut it promises nothing.
  • The full Word comparison runs on one machine. Hosted CI covers 69 of the 143 comparison fixtures; the rest need faces only Word ships (Validation). A green CI is not the whole story.
  • The security register is closed, not finished. The project's own audits filed over a hundred findings — unbounded allocations, integer overflows, unbounded recursion, hang loops, process-killing stack overflows — and all of them are now fixed, each with the attack built as a regression test, with a deterministic fuzzer (#71) running on every push to hunt for what the audits missed. That is a real change of state from earlier in the alpha, but it is a statement about the attacks that were found, not a proof none remain: see Security.

User-supplied documents

Earlier in the alpha this page said do not convert user-supplied documents at all, because the register held dozens of open findings a crafted document could exploit. That register is now empty — the memory-exhaustion, hang and stack-overflow findings are fixed and fuzz-guarded — so the categorical ban has served its purpose and is lifted.

What replaces it is the standard posture for untrusted-input processing, stated on Security and worth restating here:

  • A .docx is still attacker-controlled input, and alpha software has had no exposure to the wild. If you convert documents from the public, do it in a worker process with an OS-level memory cap and a timeout, with Limits set tight — treat isolation as the load-bearing defence, not a formality.
  • The failure modes remain denial-of-service-shaped rather than code execution — the library is pure managed code with no unsafe — so what isolation is protecting is your service's availability.

Acceptable uses today

  • Evaluation, prototyping, and fidelity testing against your own document corpus
  • Internal tooling over trusted, self-authored documents
  • Experimenting with third-party documents, with the isolation posture above where the source is genuinely untrusted
  • Contributing — testing on real documents you own and filing what breaks is exactly the help the project needs (Developers)

When this page changes

The warning was always expected to soften in stages rather than vanish at once, and the first stage has happened: the hostile-input epics are closed and a fuzzing corpus runs on every push. What remains before the alpha label comes off is a published package and a tagged release (#61), plus the planned static-analysis layer in CI (#228). Watch the issue tracker — the security label and the release issue are the honest signal of where things stand.

Clone this wiki locally