Security Policy

1. Reporting a vulnerability

Do not open a public issue. Security reports must stay private until a fix ships.

1. Email security@opensatchel.dev with:
   • A description of the vulnerability and its impact.
   • Steps to reproduce, including any test PDF or fixture file.
   • The version (or commit SHA) you tested against.
2. You will receive an acknowledgement within 72 hours.
3. We will provide a fix timeline within 7 calendar days of triage.
4. Critical vulnerabilities (remote code execution, data exfiltration, signature bypass) are targeted for a patch within 14 calendar days. Non-critical issues are scheduled for the next release.
5. Once the fix ships, we will credit you in the release notes — unless you prefer to remain anonymous.

2. Supported versions

Only the latest release receives security fixes. We do not back-port patches to older minor versions.

3. Scope

The following are in scope for security reports:

• The Open Satchel desktop application (Tauri shell + WebView frontend)
• The Rust PDF engine
• Cryptographic operations: AES-256 encryption, RSA/ECDSA signing, PKCS#11 hardware-token integration, LTV embedding
• The MCP test server (developer-machine only — relevant if it exposes a local attack surface)

Out of scope:

• Third-party dependencies with their own security policies (pdfjs, pdf-lib, Tesseract.js, Fabric.js, lopdf, etc.). Report those upstream; we update our pinned version once a fix is available.
• The marketing site or documentation content.
• Denial-of-service via malformed PDFs that cause high CPU or memory usage but no code execution — tracked as bugs, not security issues.

4. Disclosure policy

We follow coordinated disclosure:

• Reporters may publish details 90 days after the initial report, or once a fix is released — whichever comes first.
• We will not pursue legal action against researchers acting in good faith under this policy.
• We ask that you do not access, modify, or delete data belonging to other users during testing.

5. Security architecture

Open Satchel is a local-first desktop app. The primary security properties:

• No network egress by default. The only opt-in network calls are RFC 3161 TSA timestamping and OCSP/CRL lookups during PDF signing, both routed through an allow-listed Rust HTTP client. See Privacy for the complete network table.
• No telemetry, analytics, or update server.
• No accounts or authentication server. The app inherits the OS user identity.
• Source available for audit. Buyers can build from source and verify the binary matches the audited code.
• AES-256 (PDF 2.0 R=6) encryption for document protection.
• PKCS#11 hardware-token signing for non-exportable private keys.
• True content-stream redaction — redacted text is removed from the PDF, not painted over.

6. Known limitations

We publish an honest catalogue of current capability gaps in docs/KNOWN-LIMITATIONS.md in the project repository, including AES-256 R=5/R=6 decryption and CJK/RTL editing fidelity. Procurement teams are welcome to request the latest copy.

7. PGP key

A signing key for security advisories will be published here once release signing infrastructure is in place. Until then, security correspondence travels over standard TLS-secured email.