pdfcer parses PDF files by design from sources the user doesn't control — email attachments, downloads, scans. Every PDF is untrusted, potentially adversarial input. See docs/ARCHITECTURE.md §10 for the hardening this implies at the design level (resource-limit guards, fuzz-testing); this file is the disclosure process for when something slips through anyway.

pdfcer is pre-1.0 and tags portable releases regularly (currently v0.42.0), but there is still no formal version-support table — only the latest tagged release and current main are supported. An older tag will not receive a backported fix; upgrade to the latest release instead. This section gets a real support table (e.g. "last N minor releases") once the project reaches 1.0.

Note that docs/FEATURES.md is kept true at HEAD rather than at release time, so it may describe capabilities that no tag contains.

Do not open a public GitHub issue for a security vulnerability. This repository (github.com/KenM76/pdfcer) is public, but GitHub's private vulnerability reporting feature is not yet enabled on it — so the "Security → Report a vulnerability" tab most public repos show is not available here yet. Enabling it is a maintainer-side repository setting, not a documentation fix, and is an outstanding TODO — until it is enabled, there is no private-by-default channel on GitHub itself for a report. In the meantime, contact the project maintainer through their GitHub profile (github.com/KenM76) rather than filing a public issue.

When reporting, please include:

• The specific PDF file (or a minimal reproduction) that triggers the issue, if the report involves a crash, hang, or resource exhaustion. If the triggering file contains sensitive/real-world content, say so — don't attach it to any public-facing report; see docs/LEGAL.md §5 for why real-world files need careful handling even for bug reports.
• Whether the issue is a crash, a hang (possible DoS via decompression bomb or unbounded recursion — see docs/ARCHITECTURE.md §10), a memory-safety issue (unlikely given Rust, but unsafe blocks are possible in dependencies), or a logic bug with security implications (e.g. a redaction that doesn't actually remove content — see docs/ARCHITECTURE.md §5 corollary, this is treated as a security-severity bug, not a cosmetic one, given what redaction is used for).
• Rust version, OS, and pdfcer version/commit.

• Redaction that leaves content recoverable (the saved file still contains what the user asked to permanently remove) is treated as a critical severity issue, on par with a memory-safety vulnerability — the entire point of that feature is that removal is real, and a silent failure there is a trust-destroying, potentially legally-consequential bug for whoever used it. See docs/ARCHITECTURE.md §5.
• A crafted PDF causing a hang, unbounded memory growth, or a crash is treated as a real vulnerability (denial of service), not "just a parser bug" — this is exactly the adversarial-input class docs/ARCHITECTURE.md §10 exists to guard against, and any instance that gets through is evidence a guard is missing or wrong.
• Digital-signature verification incorrectly reporting a tampered document as validly signed is critical severity — the inverse (correctly-signed reported as invalid) is a correctness bug, not a security one, but still worth reporting.

No formal SLA published yet (pre-release project, single/small maintainer team). Reasonable-effort acknowledgment and fix timeline will be communicated directly in response to a report. This section should be revisited and firmed up before the first public release.