security: Diagnose-Endpoint gegen Disk-Fill haerten (Review-Befund l)

Fable-5-Review (l)+(m): /api/e2ee-diagnostics auf dem Pi las den Body ohne
Groessenlimit und haengte ihn unbegrenzt ans Log – bei oeffentlich bekanntem
DIAG_TOKEN ein Disk-Fill-DoS-Risiko. server.py: 256-KB-Body-Limit (413) +
20-MB-Log-Kappung, headless verifiziert (200/403/413). LiveKit-Plan (m)
gegen Code + Pi-Konfig gegengeprueft, stimmt.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

CHANGES.md

@@ -1232,3 +1232,7 @@
 2026-07-04 04:06 [Edit] /home/steggi/pyramid/ROADMAP.md
 2026-07-04 04:06 [Edit] /home/steggi/pyramid/PROGRESS.md
 2026-07-04 04:07 [Edit] /home/steggi/.claude-pyramid/projects/-home-steggi-pyramid/memory/pyramid-arbeitsstand.md
+2026-07-04 04:30 [Edit] /home/steggi/matrix/server.py
+2026-07-04 04:30 [Edit] /home/steggi/matrix/server.py
+2026-07-04 04:31 [Edit] /home/steggi/pyramid/PROGRESS.md
+2026-07-04 04:32 [Edit] /home/steggi/pyramid/PROGRESS.md

PROGRESS.md

@@ -13,6 +13,33 @@ Schritt (und beim Abbruch mitten im Schritt den Zwischenstand). Format:
 
 ---
 
+## 2026-07-04 – Fable-5-Review (l)+(m): Diagnose-Endpoint hatte kein Größenlimit (gefixt)
+
+**Erledigt:** Review-Pass über die zwei seit (k) dazugekommenen Arbeiten – als
+Punkte (l) und (m) im Fable-5-Review-Abschnitt abgehakt (Details dort). Bei (l)
+ein **echter Befund** am Server-Gegenpart des Admin-Token-Fixes: Der neue
+`DIAG_TOKEN` steht bewusst im öffentlichen Repo (eng begrenzt, nur Log-Anhängen) –
+aber `/api/e2ee-diagnostics` in `/home/steggi/matrix/server.py` las den
+Request-Body **ohne Größenlimit** und hängte ihn unbegrenzt an die Log-Datei an.
+Jeder Fremde hätte damit die Pi-Platte volllaufen lassen können (Disk-Fill-DoS
+auf dem Host, der auch den Homeserver trägt). Gefixt in `server.py`:
+Body-Limit 256 KB pro Upload (413 bei Überschreitung) + harte Obergrenze 20 MB
+für die Log-Datei (ältere Hälfte fliegt raus). Headless verifiziert nach
+Dienst-Neustart (kill, `Restart=always`): stats.html 200, gültiger Upload 200
+und im Log gelandet, falscher Token 403, 300-KB-Body 413; Kappungslogik isoliert
+getestet (100 Zeilen → 50, neueste überleben). Test-Einträge wieder entfernt.
+
+**Offen/Nächster Schritt:** Weiter mit dem obersten offenen ROADMAP-Punkt
+(M0 LiveKit-Token): Server-Route nach `docs/LIVEKIT_TOKEN_MIGRATION.md` bauen –
+rein additiv, Client bleibt unangetastet (heiliger Call-Pfad wartet auf PC/Gerät).
+
+**Stolperfallen:** Ein „eng begrenzter" Token im öffentlichen Repo ist nur dann
+wirklich harmlos, wenn das Endpoint dahinter auch Missbrauch begrenzt
+(Größe/Menge) – „keine Admin-Rechte" allein reicht nicht. Bei künftigen
+Endpoints mit öffentlich bekanntem Token immer an Body-/Speicher-Limits denken.
+
+---
+
 ## 2026-07-04 – LiveKit-Token-Minting: Migrationsplan geschrieben (Prep, kein Code)
 
 **Erledigt:** Für den offenen M0-Punkt „LiveKit-Token server-seitig minten"
@@ -455,6 +482,23 @@ schließt den Review ab.
   server-seitiges LiveKit-Token-Minting + nicht-Admin-Diagnose-Token als neue
   M0-Punkte aufgenommen (brauchen Bernd/Server-Zugriff). Details im
   PROGRESS-Eintrag 2026-07-04 oben.
+- [x] **(l) Admin-Token-Entkopplung (925aafb) geprüft – Client-Seite korrekt,
+  am Server-Gegenpart 1 echter Befund gefunden und gefixt (2026-07-04).**
+  Client-Diff verifiziert: neuer `pyr-diag-…`-Token stimmt mit `DIAG_TOKEN` in
+  `server.py` überein, `grep J5lax lib/ scripts/` unabhängig nachgeprüft (leer;
+  einziges verbliebenes Client-Secret ist das LiveKit-`apiSecret`, eigener
+  M0-Punkt). Befund: `/api/e2ee-diagnostics` hatte **kein Body-/Log-Größenlimit**
+  bei öffentlich bekanntem Token → Disk-Fill-DoS möglich. Gefixt + headless
+  verifiziert (200/403/413, Kappung), Details im PROGRESS-Eintrag 2026-07-04.
+- [x] **(m) LiveKit-Migrationsplan (78e4174) gegen Code + Pi-Konfig geprüft –
+  Behauptungen stimmen.** `livekit_token.dart:6` enthält das `apiSecret`,
+  Aufrufstelle `livekit_call_manager.dart:154` mit `ttlSeconds: 21600`, Grants
+  im Plan identisch mit dem Dart-Code (roomJoin/room/canPublish/canSubscribe/
+  canPublishData, metadata = Anzeigename, iss = LKMatrixPi, sub = identity),
+  `livekit.yaml` `keys:` wie beschrieben, Continuwuity antwortet auf
+  `127.0.0.1:6167` (whoami-Basis). Python-Snippet (stdlib-HS256) fachlich
+  korrekt (base64url ohne Padding, kompaktes JSON, HMAC-SHA256). Anmerkung:
+  Der Plan setzt zusätzlich `nbf`/`name` – LiveKit akzeptiert beides, harmlos.
 
 **Fazit:** Die Sonnet-5-Arbeit war handwerklich sauber; die zwei echten Lücken
 (verlorene Kommentare, fehlender Soft-Logout-Guard) hatte die abgebrochene