HiddenGit private Git · Tor v3 · SSH

Security model

HiddenGit’s controls address specific boundaries. They do not turn Tor, Docker, or SSH into universal trust mechanisms.

Assets

Boundaries and controls

Boundary Main controls Important residual risk
Internet → service Tor v3 onion routing; no default public clearnet listener endpoint compromise, traffic analysis outside HiddenGit scope
Tor → Soft Serve one fixed SSH target on private Compose network malicious/unauthorized SSH attempts still reach Soft Serve
SSH client → repository SSH key authentication + Soft Serve ACLs key theft, incorrect ACLs, host-key verification mistakes
host → containers non-root users, read-only roots, cap drop, no-new-privileges Docker daemon/host remains highly privileged
config → runtime versioned parser, duplicate/unknown rejection, fixed internal topology reviewed extensions can still widen exposure
runtime → source tree .gitignore/.dockerignore and hygiene tests manual exfiltration or external tooling
backups → storage age authenticated encryption + checksums loss/compromise of offline identity, stale backups
upstream → release pins, provenance, SBOM, vulnerability gate undisclosed vulnerabilities, compromised build infrastructure

Tor is routing, not authorization

Possession of the onion address does not grant repository permission. Soft Serve must enforce users/keys/ACLs. Tor v3 client authorization is planned as an extra enrollment/revocation layer, not a replacement for SSH authorization.

Default protocol minimization

The product uses SSH because it simultaneously carries the forge UI/commands and Git smart protocol with public-key authentication. The default profile disables:

Stats stays enabled only on container loopback. Fewer reachable protocols reduce the set of parsers/auth paths that need exposure and independent security review.

Upstream security cadence

HiddenGit tracks a pinned Soft Serve release and explicit dependency graph. A dependency override is not considered a substitute for application-level fixes. The release process therefore checks current upstream security releases and regenerates strict vulnerability evidence before tagging.

Secrets versus sensitive metadata

Private keys, database content, age identities, and tokens must never enter Git, CI artifacts, documentation builds, or shared logs. Onion hostnames, usernames, repository names, and public keys are not cryptographic secrets, but a deployment may still classify them as sensitive metadata.

See the canonical security policy for reporting and release requirements.