Security model

The proxy is designed for a trusted single-user developer workstation. The boundaries below are the load-bearing assumptions — read them before deploying anywhere else.

Locked invariants

These cannot be changed by config or environment:

• Loopback bind only. 127.0.0.1:3817, hardcoded. The host is intentionally not configurable.
• Body size cap of 100 MiB on inbound requests. Defends against runaway local clients.
• Path forwarding is 1:1. No path rewriting, no allowlist (by design — transparent proxy).
• Client-supplied X-Git-Remote is stripped before the inspection middleware runs. A local process cannot spoof attribution.
• Authorization & x-api-key are forwarded as-is. The proxy does not authenticate callers; Bifrost validates.
• Authorization values are never logged. Only has_auth=true/false boolean.
• Raw query strings are not logged. Only has_query=true/false.

Trust boundaries

┌──── Trusted ─────┐    ┌────── Untrusted ──────┐
│  the user        │    │  the network          │
│  the user's IDE  │    │  any LAN host         │
│  local processes │    │  any other user on a  │
└──────────────────┘    │  multi-user machine   │
                        └───────────────────────┘

The proxy trusts local processes on the same machine: it forwards whatever Authorization / x-api-key headers they supply.

What the proxy does NOT defend against

Multi-user hosts

On shared hosts (CI runners, jump hosts, dev servers), any local user with loopback access can use the running daemon. They can send requests with their own keys and the proxy will forward them; attribution metadata is harvested from the calling PID, not the daemon owner.

If you must run on shared hosts, restrict who can connect (firewall, peer-uid checks) before deployment. The proxy itself does not do this.

• Auth on the proxy. None. Anything reaching loopback gets forwarded.
• Secret storage. None. The proxy holds no secrets, reads no API keys; the client supplies them per-request in headers.
• Rate limiting. None. The proxy is transparent — Bifrost handles quota.
• Anti-replay / signing. None. Same as above.
• Audit ingestion. None. Logs are local. Centralized telemetry is out of scope.

Defense-in-depth measures in code

Layer	What it does
pprof guard	If pprof.enable: true, the bind address is validated at startup to be loopback (127.0.0.1, localhost, ::1). LAN binds are rejected.
http.MaxBytesHandler	100 MiB body cap, applied to all inbound.
requestLogger scrub	Authorization, x-api-key, Cookie, Set-Cookie redacted (presence-only).
Argv-safe subprocess	git remote -v, lsof, ps all use exec.CommandContext with Cmd.Dir (not git -C cwd) — no shell, no interpolation.
Timeout guards	2 s on git remote -v and process inspection; 30 s ReadHeaderTimeout.
Plaintext upstream warning	If upstream_url starts with http://, the proxy logs a startup warning so misconfigurations don’t go silent.

Cross-platform inspection caveats

• Linux /proc/<otherUser>/fd/* returns EACCES — cross-user inspection is intentionally unsupported. The proxy will simply forward without the X-Git-Remote header.
• macOS uses lsof. If lsof is missing or restricted, attribution falls back to no header.
• Windows PEB walk requires SeDebugPrivilege (which LocalSystem has by default for the machine-wide service). 32-bit target processes are unsupported and return ErrUnsupportedBitness.

What’s coming

• Optional SO_PEERCRED / LOCAL_PEERCRED peer-UID check to refuse cross-user connections on multi-user Linux/macOS hosts.
• Configurable body size cap (currently compile-time).