Skip to content

Rezeptsicherheit ​

Ein Rezept ist ausführbare Automatisierung. Name und Autor liefern Kontext, doch nur der Workflow-Körper und seine transitiven Abhängigkeiten beschreiben, was es tatsächlich tun kann.

Vertrauensmodell ​

Echo speichert, ob ein Rezept von Budgie, aus der Community oder vom Benutzer selbst stammt. Dazu kommen Herausgebermetadaten, ein Inhalts-Hash und etwaige Signaturdaten. Das sind Herkunftssignale und kein Ersatz für die Prüfung der ausführbaren Aktionen.

Die Importprüfung berechnet Fähigkeiten aus dem analysierten Workflow neu, statt einem zwischengespeicherten Manifest zu vertrauen. Ein übereinstimmender Inhalts-Hash belegt, dass der eingebettete Körper zum Hash in der Hülle passt; er beweist nicht, dass das Verhalten sicher ist. Auch Autorenidentität, Quellenbezeichnung, Beliebtheit und eine plausibel klingende Beschreibung ersetzen keine Prüfung.

Importierte Rezepte von Drittanbietern werden zur Laufzeit genau für die Aktionen kontrolliert, die in der erzeugten Aktionsreferenz als bestätigungspflichtig gekennzeichnet sind. Die Abfrage kann die Aktion ablehnen, einmalig erlauben oder diesen Aktionstyp für das Rezept dauerhaft erlauben. Bei selbst erstellter Herkunft erscheint keine Abfrage. Lokale Autoren müssen die eigenen Seiteneffekte deshalb vor einem Test selbst prüfen.

Rekursive Berechtigungen ​

Die Fähigkeitsanalyse arbeitet rekursiv. Sie durchsucht Aktionen, die unter If/Else, Schleife, Switch-Fällen und -Standard sowie Try/Catch verschachtelt sind. Wenn ein Workflow Workflow ausführen verwendet, durchsucht die Analyse außerdem den installierten Unter-Workflow und ordnet jeden Treffer seinem Quell-Workflow zu.

Zyklen zwischen aufgerufenen Workflows werden sicher unterbrochen. Ein nicht aufgelöster Unter-Workflow wird jedoch separat vermerkt, da seine Fähigkeiten unbekannt bleiben. Der aktuelle Importdialog listet die IDs solcher nicht aufgelösten Ziele nicht auf. Prüfen Sie daher jeden Knoten Workflow ausführen selbst. Behandeln Sie eine fehlende Abhängigkeit als unvollständige Prüfung: Installieren oder prüfen Sie zuerst die exakte Abhängigkeit und berechnen Sie danach die Prüfung des übergeordneten Workflows erneut.

Prüfen Sie den vollständigen Aufrufbaum erneut, sobald sich ein Ziel-Workflow ändert. Ein harmloser übergeordneter Workflow kann an eine verschachtelte Shell-, HTTP-, Datei-, Tastatur-, Plugin- oder andere Aktion mit Seiteneffekt delegieren. Die Herkunft des Stammrezepts wird an die Ausführung des Unter-Workflows weitergegeben, damit ein untergeordneter Workflow die Laufzeitfreigabe der Wurzel nicht ausweiten kann. Diese Schranke ersetzt jedoch keine Inspektion.

Seiteneffekte ​

Die erzeugte Aktionsreferenz enthält die aktuelle Berechtigung und Laufzeitbestätigung jeder Aktion. Prüfen Sie insbesondere diese Grenzen:

  • Shell und AppleScript ausführen können beliebige Befehle oder Automatisierungen ausführen. Lesen Sie den vollständigen Befehl oder das vollständige Skript einschließlich interpolierter Werte.
  • HTTP-Anfrage, Downloads und LLM-Aufrufe können Eingaben an andere Dienste übertragen. Prüfen Sie Ziele, Methoden, Inhalte, Anbieterprofile und alle vorgelagerten Daten, die sie erreichen.
  • Dateiaktionen können lokale Daten lesen, überschreiben, verschieben, kopieren, erstellen oder löschen. Lösen Sie interpolierte Pfade auf und prüfen Sie, ob ein Ziel wiederhergestellt werden kann.
  • Einfügen und Tasteneingabe senden Eingaben an die aktuell fokussierte Anwendung. Ein Fokuswechsel kann ihre Wirkung umleiten.
  • App öffnen, App beenden, Zu App wechseln und Prüfen, ob App läuft verwenden den konfigurierten App-Namen als Ziel. Sie richten sich nicht eigenständig auf die Anwendung um, die zufällig im Vordergrund liegt.
  • Plugin-Aktionen sind nur zur Laufzeit verfügbar und führen ein vom Plugin definiertes Verhalten aus. Prüfen Sie neben dem Rezeptaufruf auch das installierte Plugin.
  • LLM-Prompt garantiert kein bestimmtes Modell. Sein Text kann frühere Ausgaben enthalten. Prüfen Sie das konfigurierte Anbieterprofil und übergeben Sie niemals Anmeldedaten über gewöhnliche Variablen.

Die Laufzeitbestätigung betrifft nur Aktionen, für die die erzeugte Referenz Ja angibt. Sie ist keine allgemeine Abfrage vor jeder Datei-, Netzwerk-, Tastatur-, App-Steuerungs- oder LLM-Operation. Auch die schrittweise Ausführung ist keine Sandbox: Wenn Sie Weiter wählen, wird die tatsächlich angehaltene Aktion ausgeführt.

Aktionen, die eine Bestätigung auslösen können, werden genau einmal vor der Berechtigungsprüfung aufgelöst: Befehl, Pfad, URL oder App-Name werden zuerst interpoliert (und bei App öffnen unter macOS zu einer installierten Anwendung aufgelöst), die Abfrage zeigt diesen aufgelösten Wert, und der Handler führt anschließend exakt denselben Wert aus, ohne erneut zu interpolieren. Wörtliche {{braces}}, die über eine Eingabe hereinkommen, bleiben auf dem Weg zum Betriebssystem deshalb Daten.

Praktische Prüfung ​

Vor der Genehmigung oder ersten Ausführung:

  1. Lesen Sie jeden sichtbaren Knoten und jeden verschachtelten Kontrollflusszweig.
  2. Folgen Sie jedem Ziel von Workflow ausführen rekursiv und halten Sie bei nicht aufgelösten Zielen an.
  3. Verfolgen Sie Eingaben und Ausgaben vorwärts, insbesondere Zwischenablage, markierten Text, Transkriptionen, Umgebungswerte, Dateien und LLM-Ergebnisse.
  4. Vergleichen Sie jede Aktion mit ihren erzeugten Berechtigungs- und Bestätigungsmetadaten.
  5. Prüfen Sie exakte Befehle, Skripte, URLs, HTTP-Inhalte, Dateipfade, App-Namen, Schlüssel und Plugin-IDs.
  6. Verwenden Sie ungefährliche Testdaten. Fügen Sie niemals echte Geheimnisse in einen Testlauf oder gewöhnliche Workflow-Variablen ein.
  7. Verwenden Sie die einmalige Ausführung nur, wenn die Auswirkungen bereits verstanden sind. Nutzen Sie die schrittweise Ausführung zur Beobachtung, nicht zur Abschirmung.

Wenn Verhalten, Ziel, Herkunft oder eine Abhängigkeit unklar ist, brechen Sie den Import ab oder führen Sie den Workflow nicht aus.

Veröffentlicht unter der MIT-Lizenz.