If you discover a security vulnerability in KeeStart, please report it privately via GitHub's Security Advisory system:

1. Go to https://github.com/zinphi/KeeStart/security/advisories/new
2. Describe the vulnerability with as much detail as possible
3. We will respond within 48 hours

Do not open a public issue for security vulnerabilities.

KeeStart protects the master secret that encrypts the private credential store:

What KeeStart protects against:

• Offline brute-force attacks on the credential store (master secret never stored plaintext)
• Physical attacker who has stolen the device's storage (TPM/SEP-bound key)
• Other user accounts on the same machine (per-user working directory, 0700/0600 permissions)
• PATH hijacking attempts (KeePassXC path validated and stored inside authenticated store)

Residual risks (accepted, documented in-app):

• Same-user process can request the auth prompt — The TPM/SEP authenticates "any process running as this user". Another process running as you could present an identical prompt and, if you approve it, obtain the unwrapped secret. This is inherent to the TPM/SEP threat model and is mitigated by the principle that you shouldn't run untrusted code as your user.
• Post-open protection — Once KeePassXC is opened with the credentials, it lives in KeePassXC's memory governed by KeePassXC's own auto-lock settings. KeeStart has no control after the initial handover.

• Secrets via stdin only — Passwords are piped to KeePassXC via stdin, never passed as command-line arguments (argv is world-visible to all processes)
• Zeroized buffers — All password buffers use secrecy::SecretString and are zeroized on drop
• CSPRNG master secret — ≥256-bit from the OS's cryptographically secure RNG (OsRng)
• Hardware-wrapped — Master secret is sealed to the TPM/SEP; can only be unwrapped with the hardware auth prompt
• No network, telemetry, or IPC — KeeStart never opens network connections, never phones home, and communicates with KeePassXC only via stdin
• Minimal dependencies — Carefully audited crate set with cargo audit and cargo deny in CI
• Tamper-evident store — store.kdbx uses KDBX4's HMAC integrity protection; any modification makes it fail to open

The following cargo audit advisories are intentionally ignored in .cargo/audit.toml with a documented rationale. They are build-time-only or maintenance issues that are not reachable at KeeStart's runtime — KeeStart takes no XML input and these crates come only from the Linux GUI stack:

• RUSTSEC-2026-0194 / RUSTSEC-2026-0195 (quick-xml) — reachable only via wayland-scanner (build-time proc-macro) parsing static, vendored Wayland protocol XML. Fixed in quick-xml >= 0.41.0, but wayland-scanner 0.31.x still pins 0.39.
• RUSTSEC-2026-0192 (ttf-parser) — unmaintained but zero-unsafe, no known vulnerability; used only for Wayland client-side window decorations.

Tracking: once wayland-scanner (via winit/smithay-client-toolkit) or zbus_xml adopt quick-xml >= 0.41.0, run cargo update and remove these ignores — they should then be stale and fail the audit.