Sécurité des recettes

Une recette est une automatisation exécutable. Son nom et son auteur donnent du contexte, mais seuls le corps du workflow et ses dépendances transitives décrivent ses capacités réelles.

Modèle de confiance

Echo enregistre si une recette vient de Budgie, de la communauté ou de l'utilisateur, ainsi que les métadonnées d'éditeur, une empreinte du contenu et les éventuelles données de signature. Ce sont des signaux de provenance, pas des substituts à l'examen des actions exécutables.

La revue d'import recalcule les capacités depuis le workflow analysé au lieu de faire confiance à un manifeste en cache. Une empreinte concordante établit que le corps embarqué correspond à celle de l'enveloppe ; elle ne prouve pas que le comportement est sûr. L'identité de l'auteur, l'étiquette de source, la popularité et une description plausible ne remplacent pas davantage cette revue.

Les recettes tierces importées sont contrôlées à l'exécution pour les seules actions marquées comme exigeant une confirmation dans la Référence des actions générée. La demande permet de refuser, d'autoriser une fois ou de toujours autoriser ce type d'action pour la recette. Une provenance créée par l'utilisateur n'affiche pas cette demande : les auteurs locaux doivent donc examiner leurs propres effets de bord avant tout test.

Autorisations récursives

L'analyse des capacités est récursive. Elle parcourt les actions imbriquées sous If / Else, Loop, les cas et le défaut de Switch, ainsi que Try / Catch. Lorsqu'un workflow utilise Exécuter un workflow, l'analyse parcourt aussi le sous-workflow installé et attribue chaque résultat à son workflow source.

Les cycles entre workflows appelés sont interrompus en sécurité, mais l'analyseur enregistre séparément un sous-workflow introuvable puisque ses capacités restent inconnues. La boîte d'import actuelle ne liste pas les identifiants de ces cibles non résolues : inspectez vous-même chaque nœud Exécuter un workflow. Considérez une dépendance absente comme une revue incomplète. Installez ou inspectez d'abord la dépendance exacte, puis relancez l'analyse du parent.

Réexaminez tout l'arbre d'appels dès qu'un workflow cible change. Un parent inoffensif peut déléguer à une action Shell, HTTP, fichier, clavier, plugin ou à tout autre effet de bord imbriqué. La provenance de la recette racine se propage à l'exécution du sous-workflow afin qu'un enfant ne puisse pas élargir l'autorisation de la racine, mais ce contrôle ne remplace pas l'inspection.

Effets de bord

Consultez la Référence des actions générée pour connaître l'autorisation et la confirmation à l'exécution actuelles de chaque action. Examinez en particulier ces frontières :

• Shell et Exécuter un AppleScript peuvent lancer des commandes ou des automatisations arbitraires. Lisez toute la commande ou tout le script, y compris les valeurs interpolées.
• Requête HTTP, les téléchargements et les appels LLM peuvent transmettre des entrées à un autre service. Vérifiez les destinations, méthodes, corps, profils de fournisseur et données amont qui leur parviennent.
• Les actions de fichiers peuvent lire, écraser, déplacer, copier, créer ou supprimer des données locales. Résolvez les chemins interpolés et vérifiez si la cible est récupérable.
• Coller et Frappe clavier envoient des entrées à l'application au premier plan. Un changement de focus peut détourner leur effet.
• Ouvrir, Quitter, Basculer vers une application et Vérifier si une application est active utilisent le nom configuré comme cible ; elles ne se redirigent pas vers l'application qui se trouve simplement au premier plan.
• Les actions Plugin ne sont disponibles qu'à l'exécution et exécutent un comportement défini par le plugin. Examinez le plugin installé en plus de l'appel de la recette.
• Invite LLM ne garantit aucun modèle fixe. Son texte peut inclure les sorties précédentes : examinez le profil de fournisseur configuré et ne transmettez jamais d'identifiants dans des variables ordinaires.

La confirmation à l'exécution ne couvre que les actions pour lesquelles la référence générée indique Oui. Il ne s'agit pas d'une demande générale avant chaque opération sur un fichier, le réseau, le clavier, une application ou un LLM. Le mode pas à pas n'est pas non plus un bac à sable : choisir Suivant exécute réellement l'action suspendue.

Les actions susceptibles de demander confirmation sont résolues une seule fois, avant la vérification des autorisations : leur commande, chemin, URL ou nom d'application est d'abord interpolé (et, pour Ouvrir une application sous macOS, résolu vers une application installée), la demande affiche cette valeur résolue, puis le gestionnaire exécute exactement la même valeur sans réinterpoler. Des {{braces}} littérales arrivées par une entrée restent donc des données jusqu'au système d'exploitation.

Revue pratique

Avant l'approbation ou la première exécution :

1. Lisez chaque nœud visible et chaque branche de flux de contrôle imbriquée.
2. Suivez récursivement chaque cible Exécuter un workflow et arrêtez-vous devant toute cible non résolue.
3. Retracez les entrées et sorties vers l'avant, notamment le presse-papiers, le texte sélectionné, les transcriptions, les valeurs d'environnement, les fichiers et les résultats LLM.
4. Comparez chaque action à ses métadonnées d'autorisation et de confirmation générées.
5. Vérifiez les commandes, scripts, URL, corps HTTP, chemins de fichiers, noms d'applications, clés et identifiants de plugin exacts.
6. Utilisez des données de test inoffensives. N'insérez jamais de véritables secrets dans Exécution de test ou dans des variables ordinaires.
7. N'utilisez le mode en une fois que si les effets sont déjà compris ; servez-vous du pas à pas pour observer, pas pour confiner.

Si le comportement, la cible, la provenance ou une dépendance reste flou, annulez l'import ou n'exécutez pas le workflow.