# 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`](docs/plan.md) §7 for the full threat model and §8.2 for
the fuzzing gates.