What GitCellar actually is
GitCellar's public artifact is the gitcellar/gitcellar-crypto repository — a
zero-knowledge encryption library built on Sequoia OpenPGP (Ed25519/X25519), AES-256-GCM,
Argon2id, BIP39 24-word recovery phrases, SHA-256, and content-defined chunking. The
project's stated ambition is encrypted Git hosting; the documented architecture pipes
pushes through a webhook, content-defined chunking, per-chunk AES-256-GCM encryption,
upload to Backblaze B2, and an encrypted stream manifest. Identity material is held in a
.gckey file the README describes as "the file itself IS the key."
What GitCellar protects
- Whole-bundle confidentiality at rest: pack contents, refs, and commit metadata land inside encrypted chunks before they reach Backblaze.
- Per-user keys never leave the user's machine, so a curious storage admin or a backend breach yields ciphertext.
- Recovery is built in via a BIP39 24-word phrase plus a cloud backup envelope encrypted with a recovery-code-derived key, without an account-recovery server.
Where it gets thin in practice
- Passive server adversary only. The public crypto repo treats storage as a confidentiality sink. There is no signed-event log, no client-pinned history, and no documented detection for a server that replays, reorders, or equivocates over the manifest it serves back.
- No review or collaboration surface. The public artifact is a crypto and chunking layer, not a code platform — pull requests, review threads, comments, and access changes are not part of the spec.
- No browser/native authority separation. All clients are treated alike; the public design does not distinguish a browser convenience session from a native-trusted device, so the trust elevation that gates repository writes elsewhere is not specified.
.gckeyis the key. Identity export is a plain file with no passphrase envelope. Simple and auditable, but operationally fragile if the file is mishandled, copied, or backed up to the wrong place.- No CI story. Anything that needs to read the code (build, test, search, review tooling) needs the repo key, and the public repo does not describe a runner-scoped trust model that would let that happen without giving long-lived signing authority to a build machine.
- Maturity signal. The public repository currently shows one commit and no releases. The crypto stack reuses well-known building blocks, which is good for auditability; the protocol layer that would distinguish this from "encrypted backup of a Git bundle" is not yet public.
Where HushGit's design differs
- Active server adversary. HushGit treats the server as actively malicious. Clients verify a signed event log with signed parent-event links, pin trusted history and transparency state, and reject replay, reorder, and split views rather than trusting what the server returns.
- Witnessed transparency. Current account, repository, runner, catalog/list, and proof-bearing byte responses include checkpoint, witness, subject-map, inclusion, private-opening, and consistency proofs before clients trust them.
- Encrypted review and access surface. Pull requests, review state, comments, and access changes ride the same encrypted, signed event log as repository writes, so they are part of the protocol rather than a side-channel plaintext platform.
- Browser/native authority split. Browser-delivered JavaScript cannot approve enrollment, create repositories, upload or delete chunks, append signed repository events, or decrypt review payloads. Only native-trusted devices can.
- Repo-scoped CI runner protocol. Runners are repo-scoped principals with signed owner envelopes, encrypted job specs, runner-signed lease heartbeats, encrypted manifest and chunk material fetched only under an active lease, and encrypted result chunks — not account devices, and not a passive build box with a static key.
- Real device and runner revocation. Keyring epochs disallow future wrapping to removed devices, runner revocation immediately blocks claim, heartbeat, material fetch, result upload, and completion, and a documented recovery boundary names what a recovery key can and cannot sign.
A small team that wants a focused, auditable crypto and chunking layer for encrypted Git backups, is comfortable with a "the file is the key" identity model, and accepts that review, audit, and CI live elsewhere on unencrypted code. The crypto stack is conservative and reuses mature primitives.
You need a full encrypted code platform — signed history with client-pinned heads, witnessed transparency proofs, encrypted PR review and audit, browser vs. native authority separation, and a repo-scoped CI runner — and your threat model treats the hosting provider as actively adversarial, not just as a passive storage target.