freepdfeditor/SECURITY.md

Security policy

FreePDFEditor takes security seriously. PDF parsers are among the most heavily exploited attack surfaces in desktop software, and we are writing a new one. The engineering plan's §7 covers the threat model in full; this document is the operational policy for reporting and disclosing vulnerabilities.

Supported versions

Only the latest release line receives security fixes. The pre-1.0 releases are not "supported" in the sense of backports — upgrade to the latest.

Reporting a vulnerability

Do not open a public issue. Report privately:

• Email: security@freepdfeditor.org
• PGP-encrypted to the key fingerprint published at https://gitea.lm.je/ai-ad4/freepdfeditor/src/branch/main/SECURITY.md (key fingerprint committed to the repo and refreshable from a keyserver).

Please include:

1. A description of the issue and its impact.
2. A minimal reproducer (a PDF, a script, or step-by-step instructions).
3. The affected version and platform.
4. Whether you have already disclosed it elsewhere.

You will receive an acknowledgement within 3 business days. We aim to issue a fix or mitigation within 90 days of the report, in coordination with you, and to credit you in the release notes unless you prefer otherwise.

Coordinated disclosure

We follow a 90-day coordinated-disclosure policy. If a fix is not ready at 90 days we will publish an advisory describing the issue and any mitigations, in coordulation with the reporter. Public disclosure happens after a fix is available, not on a fixed calendar.

Scope

In scope:

• Memory-corruption bugs in any parser or codec glue reachable from a document opened by the user.
• Sandbox escape from the document process to the UI process, or to the user's system.
• Signature mis-validation, encryption bypass, or redaction failure.
• Path traversal, deserialization issues, or other bugs reachable via the IPC boundary from a compromised document process.
• Crashes reachable from a corpus file that a real user could receive.

Out of scope:

• The PDF permission bits are advisory, not a security boundary (§4.6, §7.1). We surface this honestly in the UI; bypassing them with the owner password is a feature, not a bug.
• Behaviour requiring a compromised OS account.
• Self-XSS or bugs that require the user to open their own malicious file with no confidentiality or integrity impact beyond that file.

Hardening posture

• The document process is sandboxed (seccomp-bpf + user namespaces on Linux, App Sandbox on macOS, AppContainer on Windows) from M1 — not retrofitted.
• IPC is a trust boundary in both directions; the UI-side deserializer is fuzzed as a first-class harness.
• Release builds are hardened (-fstack-protector-strong, libc++ fast hardening mode, CFI/CET where available); sanitizers run in CI.
• OSS-Fuzz integration from M2, not M8.
• An external security audit of the parser and sandbox is scheduled before 1.0 (§10, M9).

See docs/plan.md §7 for the full threat model and §8.2 for the fuzzing gates.