# ADR-008: Wire repo names are registry IDs, never paths ## Status Accepted ## Context Repo names arrive on the wire in three shapes: the git:// first-request line (`git-upload-pack ''\0host=…`), the ssh exec command string (`git-upload-pack ''`), and the http path segment (`//info/refs`). All three are attacker-controlled. Treating them as filesystem paths (even with ad-hoc sanitization) is the classic git-server traversal bug — and `docs/research/git-protocol.md` §"Security-relevant protocol notes" flags exactly this. ## Decision Wire-supplied repo names are **IDs**: opaque registry keys resolved server-side to configured storage roots. - The registry is alkgit's authoritative (repo id → storage root + visibility + ACL scope) mapping, owned by the `GitRegistry` backend trait. - Resolution failure and authorization failure are indistinguishable to the caller (ADR-007 step 2's no-existence-oracle rule). - Wire names are never joined, normalized, or canonicalized into paths. Path construction happens only from registry-resolved roots. - The same never-execute rule covers the ssh exec command string: it is *parsed* (fixed grammar: service name + quoted repo argument), never interpreted by a shell and never passed to a subprocess (convention 6's no-shelling-out invariant). Unknown commands get a fixed refusal. - The registry's own backing store is a separate decision (OQ-06). ## Consequences - Path traversal is structurally impossible on the serving path. - Repo renames/migrations are registry edits, not filesystem moves (the storage root indirection absorbs them). - The registry must be available (or cached) at session start; its unavailability is a config/ops error surfaced as session failure, never a path-guessing fallback. ## References - `docs/research/git-protocol.md` §"Security-relevant protocol notes" - `docs/research/vision.md` §"Immediate threat-model notes" - ADR-007 (the resolve-then-authorize order) - backend.md §"The trait family" (GitRegistry), OQ-06 (registry backing)