What git-remote-gcrypt actually is
git-remote-gcrypt is a Git remote helper that wraps a normal remote (SSH, HTTPS, rsync, S3, etc.) and pushes GPG-encrypted Git pack data to it. The remote sees opaque encrypted objects and a signed manifest of refs; the helper decrypts on fetch. Access is gated on possession of a recipient GPG key.
What git-remote-gcrypt protects
- Whole-repository confidentiality at the transport layer: contents, paths, commit metadata, and ref names are inside the encrypted pack.
- The remote is reduced to dumb storage. Backend RCE, host subpoena, or a curious admin yields ciphertext.
- Works over almost any storage substrate without a custom server.
Where it gets thin in practice
- Coarse-grained pushes. Pushes append a new encrypted pack and rewrite the manifest, with no object-level dedup against the remote. Compared to vanilla Git or HushGit's chunked, content-addressed pushes, large repos and frequent pushes accumulate redundant pack data.
- No review or collaboration surface. Pull requests, code review, comments, and access logs do not exist. Teams that want them push the plaintext to a second platform — defeating the point.
- Key management is GPG. Adding or removing a participant means rewrapping and redistributing keys; revocation does not retroactively protect history a former member already pulled.
- No audit trail. The remote cannot meaningfully log "who pushed what" because it cannot tell the difference between a fresh push and a force-rewrite.
- No CI story. Anything that needs to read the code (CI, search, review tooling) needs the GPG key, which usually pushes teams back to plaintext for those workflows.
Where HushGit's design differs
- Incremental encrypted pushes. Pack data is split into content-addressed encrypted chunks, so a normal push uploads only what changed.
- Encrypted PR / review protocol. Code review, comments, and access decisions live inside the encrypted, signed-event protocol, not on a separate platform.
- Append-only signed event log. Pushes and access changes produce signed events with signed parent-event links, so clients can detect tampering, reordering, and replay against their own view of the log.
- Witnessed transparency. Current hosted state is bound to signed checkpoints, external witness quorum, subject-map proofs, private openings, inclusion proofs, and local transparency pins.
- Per-device keys, real revocation. Access is granted to device keys with key epochs and a documented revocation flow, not long-lived shared GPG identities.
- Customer-controlled CI. CI runners are self-custodied by the team, so build environments inherit the same trust boundary as the clients.
A solo developer or a very small team that wants encrypted-at-rest Git on top of arbitrary existing storage, does not need code review, and can live with whole-repo pushes and GPG-style key management. It is genuinely useful in that envelope.
You need encrypted hosting and the rest of a code platform — review, access management, audit, transparency proofs, CI — without giving the host plaintext code, and without a side-channel plaintext remote for the workflow tools.