hack-house/SECURITY.md
leetcrypt ff5186a9d3 feat(hh): graceful shutdown, crypt default theme, neutralize branding, share-prep
- Graceful shutdown: Ctrl+C quits in chat (interrupts PTY while driving),
  RAII TermGuard + panic hook + SIGTERM/SIGHUP always restore the terminal
- Default theme is now "crypt" (neutral monochrome); theme sigil mirrored in
  chat/roster/help so the pentagram only renders under the "church" theme
- Neutralize inverted-pentagram branding across CLI, scripts, docs, and Cargo
  metadata (kept only in themes/church.toml + the render-time placeholder)
- Rewrite root README around hack-house; add bootstrap.sh, SECURITY.md,
  CODE_OF_CONDUCT.md, CHANGELOG.md, and issue/PR templates
- .gitignore cleanup; stop tracking .venv

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-05-31 23:23:19 -07:00

61 lines
2.6 KiB
Markdown

# Security Policy
hack-house is an end-to-end-encrypted tool. We take vulnerability reports
seriously and appreciate responsible disclosure.
## Reporting a vulnerability
**Please do not open a public issue for security vulnerabilities.**
Instead, use GitHub's private vulnerability reporting:
1. Go to the repository's **Security** tab.
2. Click **Report a vulnerability** (Private Vulnerability Reporting).
3. Describe the issue, how to reproduce it, and the impact.
If private reporting is unavailable, contact a maintainer directly rather than
filing a public issue.
We aim to acknowledge reports within a few days and to keep you updated as we
investigate and fix the issue. We'll credit reporters in the release notes
unless you prefer to remain anonymous.
## Scope
This project's security rests on a few load-bearing properties. Reports that
break any of these are especially valuable:
- **Zero-knowledge server** — the server must only ever handle ciphertext. Any
path where it can recover plaintext messages, file contents, file names, or
terminal output is in scope.
- **SRP authentication** — the room password must never traverse the network.
Anything that leaks it, enables offline cracking beyond the SRP design, or
permits authentication bypass is in scope.
- **Room key derivation** — the room key (`HKDF(password, room_salt)`) must
stay client-side. Key recovery by the server or a passive observer is in
scope.
- **Crypto parity** — the Rust client and Python server must agree on SRP +
Fernet. Divergences that weaken encryption are in scope.
- **Sandbox isolation / permissions** — bypassing the drive ACL or VM
sudo/unix-user controls (e.g. driving without a grant, escalating to
superuser without `/sudo`) is in scope.
- **WebSocket auth** — session hijacking or replay against the post-SRP
HMAC token is in scope.
## Out of scope
- The `--no-tls` / `--insecure` modes: these intentionally disable transport
security for local or trusted-tunnel (e.g. Tailscale) use. Issues that only
manifest when TLS is deliberately turned off are not vulnerabilities.
- Self-signed certificate warnings.
- Denial of service from a participant who already holds the room password
(anyone in the room is, by design, trusted with the room key).
## Operational guidance
- Always share the room password out-of-band over a trusted channel.
- Use TLS (or a trusted tunnel such as Tailscale) for anything beyond local
testing; reserve `--no-tls` for `127.0.0.1` and tunneled traffic.
- Anyone with the room password can read all traffic — treat room membership
as full trust.