You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Aufgeteilt aus #40, per expliziter Entscheidung des Nutzers ("Yes, scope it as a new feature", zusammen mit dem Hinweis, dass es eine eigene Sicherheitsbetrachtung braucht, bevor Code geschrieben wird).
Ausgangslage
#40 liefert Uninstall nur für Apps, die OpenFreshr selbst als Homebrew-verwaltet bestätigt hat (brew uninstall --cask -- <token>). Für alles andere — eine App, die z. B. direkt vom Hersteller heruntergeladen wurde und zu keinem Cask "managed" ist (Beispiel aus der Praxis: DockDoor, bevor es adoptiert wird) — gibt es aktuell keinen Weg, sie über OpenFreshr zu entfernen.
Was das bedeuten würde
OpenFreshr müsste das .app-Bundle selbst löschen (und ggf. bekannte Nebendateien) — beliebiger Dateisystemzugriff statt eines einzelnen validierten brew-Unterprozessaufrufs. Deutlich größere Angriffs-/Fehlerfläche als alles, was dieses Repo bisher macht:
Pfad-Validierung: nur innerhalb der bekannten Scan-Verzeichnisse (/Applications, ~/Applications), niemals ein von außen kommender beliebiger Pfad.
Was genau "entfernen" heißt: nur das .app-Bundle, oder auch bekannte Nebendateien (~/Library/Application Support/<App>, Caches, LaunchAgents)? Das ist die "zap"-Frage aus Apps deinstallieren #40 noch einmal, nur ohne Homebrews eigene, bereits geprüfte Zap-Stanza als Quelle der Wahrheit.
Bestätigung: NSWorkspace bietet recycle(_:) (Verschieben in den Papierkorb, reversibel) als deutlich sichereren Ansatz als ein hartes FileManager.removeItem — vermutlich der richtige Default.
Trust/Scope: sollte das für jede erkannte App angeboten werden, oder nur für welche, die zu einem Cask passen (auch unmanaged), damit wenigstens die Identität einigermaßen sicher ist?
Nicht Teil dieses Issues
Die konkrete Implementierung — das kommt erst nach einer eigenen Sicherheitsbetrachtung/einem eigenen Design-Pass, nicht direkt als Code.
Aufgeteilt aus #40, per expliziter Entscheidung des Nutzers ("Yes, scope it as a new feature", zusammen mit dem Hinweis, dass es eine eigene Sicherheitsbetrachtung braucht, bevor Code geschrieben wird).
Ausgangslage
#40 liefert Uninstall nur für Apps, die OpenFreshr selbst als Homebrew-verwaltet bestätigt hat (
brew uninstall --cask -- <token>). Für alles andere — eine App, die z. B. direkt vom Hersteller heruntergeladen wurde und zu keinem Cask "managed" ist (Beispiel aus der Praxis: DockDoor, bevor es adoptiert wird) — gibt es aktuell keinen Weg, sie über OpenFreshr zu entfernen.Was das bedeuten würde
OpenFreshr müsste das
.app-Bundle selbst löschen (und ggf. bekannte Nebendateien) — beliebiger Dateisystemzugriff statt eines einzelnen validiertenbrew-Unterprozessaufrufs. Deutlich größere Angriffs-/Fehlerfläche als alles, was dieses Repo bisher macht:/Applications,~/Applications), niemals ein von außen kommender beliebiger Pfad..app-Bundle, oder auch bekannte Nebendateien (~/Library/Application Support/<App>, Caches, LaunchAgents)? Das ist die "zap"-Frage aus Apps deinstallieren #40 noch einmal, nur ohne Homebrews eigene, bereits geprüfte Zap-Stanza als Quelle der Wahrheit.NSWorkspacebietetrecycle(_:)(Verschieben in den Papierkorb, reversibel) als deutlich sichereren Ansatz als ein hartesFileManager.removeItem— vermutlich der richtige Default.Nicht Teil dieses Issues
Die konkrete Implementierung — das kommt erst nach einer eigenen Sicherheitsbetrachtung/einem eigenen Design-Pass, nicht direkt als Code.
🤖 Filed by Claude Code at the user's request.