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).
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 interm_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: nullintauri.conf.jsonersetzen. Zweite Schranke hinter dem Markdown-Sanitizer; braucht eine Runde Prüfen, was inline nötig ist (Themes, xterm). Schondefault-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_deleteist ein Notnagel; ID beim Schreiben der JSONL vergeben, Panel löscht über die ID. -
write_app_settingverliert die übrigen App-Settings (settings.rs):read_app_settingswirft fehlende Datei, Lesefehler und kaputtes JSON in denselbenNone; nur eine fehlende Datei rechtfertigt ein frisches Objekt (Fix wie inpool.rsregister_mcp_server). -
struct Poolverliert unbekannte Keys beim Umbenennen (pool.rs). Entweder flatten-restwie inProjectConfig— oder gleich der gemeinsame read-modify-write-Helfer aufserde_json::Value, der die Fehlerklasse überall schließt. -
Archiv-Dateinamen:
create_newstattexists()(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.