~/private-repos $ threat-model

Private repos need a smaller trust boundary.

GitHub-style platforms can protect access, but the host still runs the systems that store, index, review, and serve your code. HushGit is zero-knowledge code hosting: your code is encrypted on your machine, before it leaves it. The server stores ciphertext. We can't read it. Subpoenas can't read it.

alpha access is reviewed by a human

~/threat-model $ cat 01-problem.md

GitHub-style private repos are private by policy, not by architecture.

They hide code from other users, not from the system that stores, indexes, and serves it. Three structural consequences follow.

01 · host read path

The platform is in the trust boundary.

Access controls protect you from other users. They do not remove the host, its employees, its tokens, or its internal services from your source-code threat model.

02 · breach afterlife

A host breach does not end at containment.

If platform source code is copied, attackers can study it forever: auth paths, service boundaries, CI conventions, feature flags, tests, and forgotten code that may still run.

03 · legal plaintext

Legal requests can reach it.

Subpoenas, warrants, foreign jurisdictions, NSLs. None of that requires your cooperation if your code platform holds the keys.

May 2026 / GitHub internal repos

GitHub update ↗

This is what source-code exposure means.

GitHub says it is investigating unauthorized access to internal repositories after an employee-device compromise involving a poisoned VS Code extension. GitHub also says it currently has no evidence that customer enterprises, organizations, or repositories were impacted. That is the right distinction, but it is not the end of the story: once internal source is outside the company, every private implementation detail can become attacker research material.

March 2026 / CVE-2026-3854

GitHub post ↗

The earlier RCE showed the same trust boundary.

GitHub validated and fixed the git push pipeline RCE on GitHub.com in under two hours and reported no customer-data exfiltration beyond researcher testing. Excellent response still leaves the architectural lesson intact: if the server can read private repositories, a backend execution bug can become a source-code exposure bug.

what an attacker does with leaked platform source

Exploit research gets cheaper.

Attackers no longer need to infer how the platform works from behavior. They can read handlers, permissions checks, token flows, background jobs, and tests offline until something breaks.

Secrets and assumptions become clues.

Even rotated credentials leave names, scopes, deployment shapes, service relationships, and incident playbooks behind. That context makes the next campaign sharper.

Customer impact becomes a path, not a guess.

A leaked host codebase gives adversaries a map from internal services to the customer data those services can reach. Encryption changes what is at the end of that path: ciphertext instead of source.

~/threat-model $ cat 02-architecture.md

Encrypt before push. Decrypt after pull. The server is untrusted storage with proofs.

Plaintext exists on your device and your teammate's device — nowhere else. Everything that crosses the trust boundary is signed ciphertext, and every trusted server state must come with a witnessed transparency proof.

trust-boundary.map plaintext ⇄ ciphertext ⇄ plaintext

YOUR DEVICE trusted

repo key chacha20-poly1305

device keys ed25519 / x25519

plaintext ✓ readable

HUSHGIT SERVER untrusted

objects

refs

reviews

proofs witnessed

our keys ∅ none

zero knowledge · cannot read · must prove state

TEAMMATE trusted

device keys ed25519 / x25519

repo key unwrapped

plaintext ✓ readable

$ keys

Per-repo content keys.

Symmetric key per repo, wrapped to each member's device public keys. Add a teammate, rotate keys, revoke a device — auditable, signed, append-only.

$ review

Encrypted PR review.

Diffs computed in your client. Comments, threads, approvals — encrypted to us, readable to your team. Same review workflow, opaque to the platform.

$ proofs

Witnessed server state.

Every trusted account, repo, runner, catalog, and byte-body read is checked against signed checkpoints, witness quorum, subject proofs, private openings, and local pins.

$ ci

Self-custodied CI.

Bring-your-own runner. Your code only gets decrypted on compute you control. No magical managed Actions; nothing readable in someone else's VM.

~/threat-model $ cat 03-limits.md

The honest fine print. If we hide this from you now, you should not trust us later.

A threat model is only useful if it says what is out of scope. Here is ours, including the rows that are not solved.

✓ solved

Storage / database compromise

Attacker gets ciphertext blobs. Useless without your device keys.

✓ solved

Backend RCE (clients unmodified)

Keys never touch our servers. Decryption happens in signed clients we cannot rewrite.

△ mitigated

Backend RCE + web app tampering

Pure-web clients are vulnerable to malicious JS served from a compromised web origin. Use the native CLI or desktop path for sensitive repos; release signing, reproducible builds, and release/build transparency are still required hardening for that channel.

△ mitigated

Server split view

Current server state is verified against witnessed checkpoints and local pins. A hidden fork now needs witness-quorum failure, witness rollback, or permanent isolation from honest witnesses and monitors.

✗ not solved

Hosted CI/CD compromise

CI must decrypt to build. Once your code is decrypted on a runner you don't control, we cannot protect it. We integrate with customer-controlled runners only — by design.

✗ not solved

Malicious or revoked collaborator

Anyone who legitimately had the repo, has the repo. Key rotation protects future commits, not past ones. This is reality, not a crypto flaw.

~/compare $ diff --keep-honest

Where code platforms actually stand on encryption. Including where the alternatives beat us.

A buyer in this audience is mentally building this table anyway. We'd rather build it for you, honestly, with the rows you actually care about.

HushGit encryption and workflow comparison against GitHub Private, GitLab self-managed, git-crypt, git-remote-gcrypt, Keybase Git, and GitCellar.
Capability	◆ US HushGit	GitHub Private	GitLab self-managed	git-crypt	git-remote-gcrypt	Keybase Git	GitCellar
Confidentiality
File contents encrypted at rest, end-to-end	yes	no	no	yes	yes	yes	yes
Commit messages, refs, branch names encrypted	yes	no	no	no	yes	partial	yes
PR / code review encrypted end-to-end	yes	no	no	n/a	n/a	n/a	n/a
Review comments & threads encrypted	yes	no	no	n/a	n/a	n/a	n/a
Trust model
Server can decrypt your code	no	yes	yes	no	no	no	no
Provider staff have technical read access	no	yes	partial	no	no	no	no
Survives a backend RCE	yes	no	no	yes	yes	yes	yes
Subpoena yields readable code	no	yes	yes	no	no	no	no
Witnessed split-view defense for hosted state	yes	no	partial	n/a	n/a	no	no
Workflow
Incremental push (no force-push on history)	yes	yes	yes	yes	no	partial	partial
Modern PR review UI	yes	yes	yes	no	no	no	no
Built-in key rotation & revocation	yes	yes	yes	partial	no	partial	partial
Audit log of access changes	yes	yes	yes	no	no	no	no
CI / build
Source code leaves your control for CI	no	yes	partial	n/a	n/a	n/a	n/a
Customer-controlled runners only (by design)	yes	no	partial	n/a	n/a	n/a	n/a
Transparency
Proof-bearing API responses and offline evidence	yes	no	partial	n/a	n/a	no	no
Release / web build transparency	partial	no	partial	partial	partial	no	partial
Warrant canary	yes	no	no	n/a	n/a	partial	n/a

● yes ◐ partial ○ no last updated 18 june 2026 · we keep this honest

※ git-crypt, gcrypt, and the public GitCellar crypto repo are encryption building blocks rather than full code platforms — review, collaboration, and access management still happen elsewhere on your unencrypted code. We score them ✓ where they apply and "—" where the row is out of scope.

~/audience $ ls

Built for code that is the company.

AI labs

Model code, training pipelines, eval harnesses — the IP your investors are actually paying for.

Crypto & wallets

Signing logic, custody flows, MEV strategy. Leak = exploit = chain-level loss.

Defense-adjacent

Dual-use code, ITAR-sensitive software, autonomy stacks. Compliance starts with confidentiality.

Legal-sensitive startups

Health, finance, anything where a code-host incident becomes a board-level event.

~/origin $ git log --reverse

We are building for the day your host is the headline.

HushGit started when the GitHub push pipeline RCE became public, and the May 2026 internal repository incident made the lesson harder to ignore. This is not about GitHub being uniquely careless. It is about the hidden assumption every plaintext code host makes: a "private repo" is still readable to the infrastructure that stores and serves it, and platform source-code exposure gives attackers a durable map of that infrastructure.

We've shipped infra at platforms you've used, audited cryptosystems that got breached anyway, and watched the academic E2EE-Git work mature. The forcing function is simple: ship zero-knowledge Git as a product, not a paper, with the server removed from your source-code threat model.

HushGit is a small security-focused team. No managed CI ambitions. No ML on your code. No "AI features". Just the smallest possible surface that still feels like Git.

+ proof-bearing open protocol + reproducible builds planned + no telemetry by default

~/faq $ man hushgit

Questions a security review asks first.

Is this just git-crypt with a website?

No. git-crypt encrypts selected files, not metadata, refs, commit messages, or PR review state. We encrypt the whole workflow.

How is this different from git-remote-gcrypt?

gcrypt works but treats every push like a force-push and re-uploads on history growth. We use modern E2EE-Git constructions with incremental, content-addressed encryption.

How is this different from GitCellar?

GitCellar's public repo is a crypto/chunking library for backing up Git bundles. We specify a full hosting protocol: signed event log, witnessed transparency proofs, encrypted PR review, browser/native authority split, and customer-controlled CI runners.

Can the server show different histories to different users?

Current server-backed state is verified against witnessed checkpoints, subject-map proofs, private openings, and local pins. A hidden split view needs witness-quorum failure, witness rollback, or permanent isolation from honest monitors and peers.

Can you run on our infra?

Self-managed deployment comes after the cloud alpha. The crypto is the same either way; we don't have keys in either deployment.

Will there be managed CI?

No. CI has to decrypt source code to build it, so HushGit integrates with customer-controlled runners instead of hosted build workers.

What about Copilot-style assistants?

Not on roadmap. Sending your code to a model provider would defeat the entire point.

Pricing?

Per-seat, per-repo, with a free tier for small teams once we exit alpha. Founders get grandfathered pricing.

~/join $ request-alpha

Stop trusting GitHub-style privacy with company-defining code.

we'll write back personally · no marketing, ever