Trilltechnician/hack-house
1
1
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
65df12de9e
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

2.6 KiB
Raw Blame History

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.