What does HushGit treat as trusted?
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, once implemented, reviewed release artifacts with a reproducible build process. Native bootstrap does not attest the app binary on each request.
What does HushGit treat as untrusted?
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.
What does the attacker get?
The model assumes an attacker can read, modify, delete, reorder, or replay server-side data; attempt equivocation by showing different histories to different users; observe timing, rough request sizes, account membership, and IP metadata; and compromise an account session without obtaining the user's device private key.
What protections does the design require?
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. Witnessed transparency checkpoints, subject-map proofs, private leaf openings, and monitors make split views fail verification or become portable evidence. Key rotation and no future wrapping to removed devices protect future data after membership changes.
Where does transparency fit?
Transparency is an integrity boundary, not a confidentiality boundary. The server publishes opaque committed leaves, a subject-state map, and signed checkpoints cosigned by configured external witnesses. Clients pin the accepted checkpoint and subject state locally, then require consistency from that pin on later account, repository, runner, catalog/list, and proof-bearing byte reads. Release and web build transparency are still separate future work.
Where does account authentication stop?
Account registration and sign-in use OPAQUE so raw passwords never cross the server boundary. Session tokens are bearer credentials for account-scoped requests, not proof-of-possession device tokens. A stolen session can be replayed until expiry or logout, but it must not be enough to create repositories, approve device enrollment, upload or delete chunks, or append signed repository events without a registered native-trusted device or recovery private-key signature.
What is the browser boundary?
Browser-created accounts are convenience accounts until the native CLI or desktop path completes native bootstrap with a fresh OPAQUE password proof. Browser-held signing keys must stay non-extractable and browser-convenience devices can request or display enrollment state, but they cannot approve trust elevation or perform repository mutations.
What operational limits are security-relevant?
Auth rate limits are durable PostgreSQL-backed guardrails for registration, login, account recovery, device registration, and enrollment so counters survive restarts and are shared across server instances. Session-token authentication also has a process-local database-load shield for protected data-plane routes. These controls bound guessing and spray behavior, but they are operational defenses rather than confidentiality boundaries.
Where is the keyring trust boundary?
Repository keyrings are not trusted from snapshots alone. Clients fetch referenced keyring-change objects, replay them from the local history pin's trusted head and state, and verify signatures against that replayed prior state before accepting any candidate snapshot. This prevents a compromised storage service from silently rewriting devices, recovery policy, or wrapped keys behind the same apparent keyring head.
What does transparency still assume?
The non-equivocation claim depends on at least one honest witness in every accepted quorum, durable witness state, client-side protection for local transparency pins, and eventual connectivity to an honest witness, peer, or monitor. If a witness identity is rolled back to an older valid state file, or a client is permanently isolated from every honest comparison point, that deployment has moved outside the claim.
What is the recovery boundary?
Personal recovery kits are decrypted only on the replacement device. The recovery flow passes recovery material only to the child Git process it launches, so Git, the remote helper, and subprocesses or hooks launched during that command are inside the trusted recovery boundary. A recovery kit plus its recovery code is a single-factor offline credential for repo-scoped recovery keys and should trigger rotation or revocation after suspected exposure.
What does the MVP explicitly leak?
The MVP may leak organization and account existence, membership edges needed for billing/admin, timing, approximate encrypted object sizes, public transparency-log update volume, push/pull activity frequency, and network-level metadata. It should not leak repo names unless customers opt in, branch names, tags, file paths, commit messages, pull request titles, pull request descriptions, comments, review decisions, CI job names, or CI logs containing decrypted code unless those logs are generated and stored by a customer-controlled runner.
What does revocation actually do?
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.