hushgit
join waitlist →

What HushGit removes from the server threat model

The HushGit hosting provider must not be able to read private source code, branch names, commit messages, pull request content, review state, repo keys, or CI secrets.

Trusted components

The trusted components are a user device running a signed CLI or desktop app, the user-controlled key store, customer-controlled CI runners when they are given repo keys, and reviewed release artifacts with a reproducible build process.

Untrusted components

HushGit cloud, object storage, the server-side database, the CDN, and browser-delivered JavaScript are untrusted for confidentiality. Network transport is also outside the confidentiality boundary except for availability and traffic metadata.

Required protections

Client-side encryption prevents server reads. Signed writes and signed manifests prevent silent repository corruption. Monotonic signed event chains and client state pinning defend against old refs. Key rotation and no future wrapping to removed devices protect future data after membership changes.

Explicit MVP leakage

The MVP may leak organization and account existence, membership edges needed for billing/admin, timing, approximate encrypted object sizes, push/pull activity frequency, and network-level metadata. It should not leak repo names unless customers opt in, branch names, file paths, commit messages, pull request text, review decisions, or CI logs containing decrypted code.

Revocation semantics

Default revocation is future-access-only. Removed members may retain plaintext or key material previously accessible to their devices. Stronger revocation requires key rotation, re-encryption, and sometimes history rewrite.