75 lines
3.0 KiB
Markdown
75 lines
3.0 KiB
Markdown
# 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. |