---
category: design
tags: [infrastructure, security, git, auth]
last_updated: 2026-03-19
confidence: medium
---

# Git HTTP Access

Design for exposing git clone/pull access to wiki repos, authenticated via the existing MCP bearer token.

## Current State

### What exists in otterwiki (upstream)

Otterwiki has native git smart HTTP endpoints (`/.git/info/refs`, `/.git/git-upload-pack`, `/.git/git-receive-pack`) in `otterwiki/remote.py`. These are:
- Gated by `GIT_WEB_SERVER` config (default: `False`)
- Authenticated via HTTP Basic Auth against otterwiki's own `user` table

### What exists in robot.wtf

- `GIT_WEB_SERVER` is not seeded in `_init_wiki_db()` — defaults to off for all wikis
- There's an unfinished `GitHttpBackend` class in `app/git_http.py` — read-only, no auth, **not mounted in production**
- Per-wiki MCP bearer tokens already exist (`mcp_token_hash` in `wikis` table, displayed in management UI)

### The auth gap

Otterwiki's native git auth checks credentials against its own `user` table via HTTP Basic Auth. But robot.wtf users authenticate via ATProto OAuth — they have no passwords in otterwiki's user table. If `GIT_WEB_SERVER` were enabled, git auth would either fail for everyone (no usable credentials) or, if someone populated the user table directly, bypass the platform's collaborator ACL.

The system is currently secure by coincidence (feature off + no passwords), not by design.

## Proposed Design

### Reuse MCP bearer tokens for git auth

The simplest approach: git HTTP Basic Auth accepts the wiki's MCP token as the password. Same token, two protocols.

```
git clone https://testuser:mcp_TOKEN@slug.robot.wtf/.git/
```

Or equivalently, git prompts for credentials and the user pastes the MCP token as the password (username is ignored).

### Why this works

- Tokens already exist and are already displayed in the management UI
- Token verification infrastructure exists (`WikiModel` stores and checks `mcp_token_hash`)
- No new auth system needed
- Users who have the MCP token already have full wiki access — git read access is not an escalation

### Implementation

1. **New git HTTP handler** (not otterwiki's native one): Build on the existing `GitHttpBackend` in `app/git_http.py`. Add:
   - HTTP Basic Auth that extracts the password and verifies against `mcp_token_hash`
   - Read-only (git-upload-pack only, git-receive-pack returns 403)
   - Mount at `/.git/` on wiki subdomains

2. **Block otterwiki's native git endpoints**: Ensure `GIT_WEB_SERVER` stays off. Consider explicitly seeding it as `False` in `_init_wiki_db()` and/or having the resolver intercept `/.git/` routes before they reach otterwiki.

3. **No changes to otterwiki upstream**: All git HTTP handling lives in robot.wtf's middleware layer.

### Read-only for v1

Git push (receive-pack) is blocked. Reasons:
- Push requires merge conflict handling, branch protection, and hook infrastructure
- The wiki engine expects to be the sole writer to the git repo
- MCP write access goes through the API (which validates content, updates caches, etc.)

### Access control

- Only wikis with an MCP token can be cloned (token must exist and match)
- The token grants the same access level as MCP: read + write via API, read-only via git
- Revoking/regenerating the MCP token immediately revokes git access too

## Use Cases

1. **Template updates**: `git remote add template https://github.com/schuyler/robot-wtf-template.git && git fetch template && git rebase template/main` — this doesn't require platform git access (GitHub is the remote). But pushing the rebased result back requires either git push access or the API.

2. **Local editing**: Clone wiki, edit in a local editor, push back. Blocked by read-only constraint in v1. Could be enabled later with receive-pack + token auth.

3. **Backup**: Clone the wiki repo for offline backup.

## Relationship to Template Repo

The template repo update flow (`git fetch template && git rebase template/main`) fetches from GitHub (public, no auth needed). The rebase happens locally. Pushing the result back to the wiki requires write access, which v1 doesn't provide via git.

Options for applying template updates in v1:
- Management UI "Update from template" button (platform does the fetch + rebase server-side)
- MCP tool that triggers the same operation
- Future: git push with token auth

## Risks

- **Token exposure in git config**: Users may store the token in `~/.netrc` or git credential helpers. This is standard for token-based git auth (same as GitHub PATs). Document that tokens should be treated as secrets.
- **Blocking otterwiki's native git endpoints**: Must be airtight. If a code path re-enables `GIT_WEB_SERVER`, the native endpoints (with their own auth) become reachable. Defense in depth: seed `GIT_WEB_SERVER=False` in `_init_wiki_db()` AND intercept `/.git/` in the resolver.

## Implementation Phases

1. Seed `GIT_WEB_SERVER=False` explicitly in `_init_wiki_db()` (defensive)
2. Add token auth to `GitHttpBackend`
3. Mount at `/.git/` on wiki subdomains, read-only
4. Management UI: show git clone URL alongside MCP token
5. (Future) Write access via receive-pack