Files
claude-ai-control/OFFENE-PUNKTE.md
T
marcus hinz 494495bb94 Offene Punkte aufgeräumt; Projekt-Config auf .ai-control/ migriert
Erledigtes raus (Umbau .ai-control/UUID, Dialog-Redesign, Sicherheitsrunde II),
ACL-Ergebnis dokumentiert, Punkte in 'Entscheidung nötig' und 'Go genügt'
gruppiert. ai-control.json ist durch .ai-control/config.json + icon.png
ersetzt (App-Migration).
2026-07-20 12:22:32 +02:00

3.6 KiB

Offene Punkte — bei jedem Start prüfen und abhaken

Erledigt und rausgeräumt (2026-07-20, Details in der Git-Historie): Umbau auf .ai-control/config.json mit Projekt-UUID + Name (Registry maschinenlokal inkl. Pool, Icon im Projekt, Migration beim Start, Import-Prüfung); Settings-Dialog-Redesign (Gruppen, fester Kopf/Fuß, feste Höhe); Sicherheitsrunde II: term_start-Label-Prüfung, archive_panel ohne dir, write_panel(path) mit Allowlist + 2-MB-Limit, write_atomic überall, write_secret_file mit create_new+0600, PTY-Env ohne ANTHROPIC-Keys, check_name in den Panel-Pfaden, Bidi-Filter in den Befehlskacheln.

Die ACL-Frage aus der Sicherheitsrunde ist entschieden (gegen tauri 2.11.5 verifiziert): Die Fenster-ACL greift für App-Commands nicht — ohne __app-acl__-Manifest prüft Tauri eigene Commands bei lokalem Origin gar nicht; die windows-Liste in den Capabilities beschränkt nur die Plugin-Permissions. Daraus folgt der erste Punkt unten.

Entscheidungen nötig

  • App-ACL-Manifest einführen? Jedes Fenster darf derzeit jedes App-Command rufen (delete_project, set_archive_home_cmd, …); abgesichert ist nur der PTY-Pfad (Label-Prüfung in term_start). Ein App-Manifest (eigene Permissions pro Command, in den Capabilities pro Fenster zugeteilt) wäre die strukturelle Antwort — spürbarer Umbau, Umfang festlegen.

  • csp: null in tauri.conf.json ersetzen. Zweite Schranke hinter dem Markdown-Sanitizer; braucht eine Runde Prüfen, was inline nötig ist (Themes, xterm). Schon default-src 'self' schnitte auswärtige Requests und Fremdnavigation ab.

  • Archiv-Ordner-Handling. Beim Setzen explizit bestätigen statt still anlegen; Wechsel eines gesetzten Archiv-Homes braucht eine Migrationsmöglichkeit (Dokumente mitnehmen oder liegen lassen). Kritisch: echte Nutzerdaten, nichts implizit verschieben.

  • Projekt sauber löschen. Alle Ressourcen des Projekts entfernen (Config, Icon, Archiv-Rechte in .claude/settings.json, Registry-Eintrag) — mit Vorschau, was entfernt wird. Umfang festlegen.

  • macOS: API-Key kurz in der security-Kommandozeile sichtbar (macos.rs, ps-sichtbar). Bewusst zurückgestellt, bis eine macOS-Session zum Testen verfügbar ist.

Go genügt (Weg ist klar)

  • Command-History: stabile ID je Eintrag. Der cmd-Text-Abgleich in commands_delete ist ein Notnagel; ID beim Schreiben der JSONL vergeben, Panel löscht über die ID.

  • write_app_setting verliert die übrigen App-Settings (settings.rs): read_app_settings wirft fehlende Datei, Lesefehler und kaputtes JSON in denselben None; nur eine fehlende Datei rechtfertigt ein frisches Objekt (Fix wie in pool.rs register_mcp_server).

  • struct Pool verliert unbekannte Keys beim Umbenennen (pool.rs). Entweder flatten-rest wie in ProjectConfig — oder gleich der gemeinsame read-modify-write-Helfer auf serde_json::Value, der die Fehlerklasse überall schließt.

  • Archiv-Dateinamen: create_new statt exists() (free_path, TOCTOU). Beim Maschinen-Sync können zwei Rechner in derselben Minute mit gleicher Titelzeile schreiben; Kollisionsfreiheit gehört ins Dateisystem. Mitzudenken: was der Sync selbst bei Namensgleichheit tut.

Hintergrund (unverändert gültig)

Pools trennen Konfiguration, nicht Zugriff: Die Keychain-Einträge sind bewusst über /usr/bin/security bzw. Keyring promptfrei lesbar — jeder Prozess des Nutzers kann jeden Pool-Key lesen. So gewollt, kein Isolationsversprechen.