2027a/auroscope

Watch

Fork 0

[Decision D12] Adopter le modèle de menace et les quality gates de test #13

New issue

Closed

opened 2026-08-30 20:42:57 +00:00 by hephaistos · 5 comments

hephaistos commented

2026-08-30 20:42:57 +00:00

Owner

MODE: DECISION

Statut

Proposé. Réponse puis go explicite avant clôture.

Question

Quel adversaire AURoscope prétend-il arrêter, quels risques restent assumés et quelles preuves sont obligatoires avant v1 ?

Frontières proposées

Hostiles : dépôts/recettes/fichiers Git, metadata/comments/fixtures, upstreams, contenu modèle et fournisseur LLM. Trusted mais versionnés/testés : Paru/Pacman/makepkg/Git. L’humain décide. Un autre processus du même UID est un risque partiellement mitigé; un compte utilisateur compromis est hors garantie. Pacman seul franchit normalement sudo/root.

Menaces majeures

Symlink/traversal, prompt injection, substitution après revue, replay d’approbation, cache binaire, terminal escapes, PATH/editor/config, secrets/sudo, concurrence Pacman, cleanup escape, Git helpers, partial upgrades, exfiltration LLM et corruption SQLite.

Tests obligatoires proposés

Unit/fuzz

Argv, formats Paru, manifestes byte-safe, règles, JSON LLM, transitions, XDG, escaping; fuzz paths/parsers/allocations.

SQLite

Migrations, FK, claim concurrent, WAL/busy timeout, crash après claim, quick_check, backup/restore/rétention.

Contrats exécutables

Chaque couple Paru/Pacman supporté : sélection stdout/stderr, --order, hook cwd/env/ordre/cache, skipreview, signaux/TTY/exit, Pacman print/lock.

Sécurité

Mutations commit/fichier/mode/symlink/untracked, inode swap, replay/expiry/double claim, prompt injection/schema bomb, crash à chaque transition, marqueurs prouvant aucune exécution de PKGBUILD pendant inspection.

E2E Arch jetable

Repo-only, mixte repo/AUR, upgrade avec defer/reject, sélection native, différentiel, échecs, annulations, cache altéré, migrations/cleanup, packaging AURoscope. Jamais la workstation réelle.

Recommandation

Adopter ces frontières et exiger les preuves d’intégration réelles avant de qualifier v1.

Réponse attendue

Accepte/amende menaces, exclusions ou gates. ADR/clôture uniquement après ton go.

Documentation

https://git.2027a.net/2027a/auroscope/src/branch/design/technical-contracts/docs/architecture/design-proposals.md

Protocole automatique de décision

Ce ticket reste en discussion et n’autorise aucune implémentation.
Les commentaires ordinaires poursuivent la discussion avec Hephaistos dans le ticket.
Quand la dernière proposition concrète te convient, publie un commentaire dont le contenu est exactement :

GO DECISION

Ce signal transfère automatiquement le ticket à Hephaistos pour consigner l’ADR, mettre à jour les documents de design, vérifier les changements et fermer le ticket.
GO DECISION n’autorise ni code de production ni plan d’implémentation; ce travail doit avoir son propre ticket MODE: EXECUTION.

MODE: DECISION ## Statut **Proposé.** Réponse puis **go explicite** avant clôture. ## Question Quel adversaire AURoscope prétend-il arrêter, quels risques restent assumés et quelles preuves sont obligatoires avant v1 ? ## Frontières proposées Hostiles : dépôts/recettes/fichiers Git, metadata/comments/fixtures, upstreams, contenu modèle et fournisseur LLM. Trusted mais versionnés/testés : Paru/Pacman/makepkg/Git. L’humain décide. Un autre processus du même UID est un risque partiellement mitigé; un compte utilisateur compromis est hors garantie. Pacman seul franchit normalement sudo/root. ## Menaces majeures Symlink/traversal, prompt injection, substitution après revue, replay d’approbation, cache binaire, terminal escapes, PATH/editor/config, secrets/sudo, concurrence Pacman, cleanup escape, Git helpers, partial upgrades, exfiltration LLM et corruption SQLite. ## Tests obligatoires proposés ### Unit/fuzz Argv, formats Paru, manifestes byte-safe, règles, JSON LLM, transitions, XDG, escaping; fuzz paths/parsers/allocations. ### SQLite Migrations, FK, claim concurrent, WAL/busy timeout, crash après claim, quick_check, backup/restore/rétention. ### Contrats exécutables Chaque couple Paru/Pacman supporté : sélection stdout/stderr, `--order`, hook cwd/env/ordre/cache, skipreview, signaux/TTY/exit, Pacman print/lock. ### Sécurité Mutations commit/fichier/mode/symlink/untracked, inode swap, replay/expiry/double claim, prompt injection/schema bomb, crash à chaque transition, marqueurs prouvant aucune exécution de PKGBUILD pendant inspection. ### E2E Arch jetable Repo-only, mixte repo/AUR, upgrade avec defer/reject, sélection native, différentiel, échecs, annulations, cache altéré, migrations/cleanup, packaging AURoscope. Jamais la workstation réelle. ## Recommandation Adopter ces frontières et exiger les preuves d’intégration réelles avant de qualifier v1. ## Réponse attendue Accepte/amende menaces, exclusions ou gates. ADR/clôture uniquement après ton **go**. ## Documentation - https://git.2027a.net/2027a/auroscope/src/branch/design/technical-contracts/docs/architecture/design-proposals.md ## Protocole automatique de décision - Ce ticket reste en discussion et n’autorise aucune implémentation. - Les commentaires ordinaires poursuivent la discussion avec Hephaistos dans le ticket. - Quand la dernière proposition concrète te convient, publie un commentaire dont le contenu est exactement : ```text GO DECISION ``` - Ce signal transfère automatiquement le ticket à Hephaistos pour consigner l’ADR, mettre à jour les documents de design, vérifier les changements et fermer le ticket. - `GO DECISION` n’autorise ni code de production ni plan d’implémentation; ce travail doit avoir son propre ticket `MODE: EXECUTION`.

hephaistos added the

labels

2026-08-30 20:45:49 +00:00

mathieu commented

2026-08-30 21:47:34 +00:00

Owner

On cherche uniquement à donner des indices à l'utilisateur pour éviter des attaque par chaîne d'approvisionnement via le AUR. Attention à ne pas faire de sur-ingéniérie et a limiter le scope a ça. On a pas besoin de se protéger de la machine locale. Sa sécurité est la responsabilité de l'utilisateur

hephaistos commented

2026-08-30 23:19:39 +00:00

Author

Owner

Ticket classé comme décision humaine. La discussion continue ici, mais aucune implémentation ni ADR accepté ne sera produit tant que Mathieu n’aura pas publié exactement GO DECISION dans un commentaire distinct.

Ticket classé comme décision humaine. La discussion continue ici, mais aucune implémentation ni ADR accepté ne sera produit tant que Mathieu n’aura pas publié exactement `GO DECISION` dans un commentaire distinct.

hephaistos commented

2026-08-30 23:24:08 +00:00

Author

Owner

Je vois trois niveaux possibles :

A — modèle large actuel : couvre aussi l’hôte local, TOCTOU par un processus du même UID, replay, corruption SQLite, concurrence Pacman, etc. C’est robuste, mais clairement surdimensionné pour AURoscope.
B — périmètre chaîne d’approvisionnement AUR : traite comme hostiles le PKGBUILD, les fichiers de recette, les sources/upstreams et leurs métadonnées. AURoscope les inspecte, signale des indices compréhensibles et laisse toujours la décision à l’utilisateur. La machine locale, le compte utilisateur, Pacman/Paru/makepkg et les autres processus locaux sont hors modèle de menace.
C — aucun gate sécurité dédié : simple à livrer, mais on ne prouve même pas que l’outil analyse sans exécuter la recette ni que ses alertes essentielles restent stables.

Ma recommandation actuelle est B, avec des gates v1 volontairement courts :

tests sur un corpus de recettes bénignes et suspectes couvrant les règles/indices annoncés ;
preuve que la phase d’inspection n’exécute ni PKGBUILD ni source du paquet ;
tests de restitution : alertes lisibles, provenance de l’indice, erreurs d’analyse explicites, aucune décision automatique ;
un E2E Arch jetable confirmant le flux analyse → indices → décision humaine avant installation.

Je retirerais des gates v1 les protections contre processus local hostile, inode swap, replay d’approbation, corruption/backup SQLite, concurrence Pacman, PATH/editor, cleanup escape et durcissement général de sudo. On conserve seulement les tests de robustesse nécessaires au fonctionnement de l’application, sans les présenter comme une garantie contre une machine locale compromise.

Autrement dit, AURoscope fournit une aide à la revue contre le risque de chaîne d’approvisionnement AUR; ce n’est ni une sandbox, ni un antivirus, ni une frontière de sécurité locale. Cette recommandation reste en discussion et ne vaut pas acceptation de la décision.

Tu as raison : la proposition initiale débordait largement le besoin produit. Elle mélangeait la détection d’indices de compromission AUR avec le durcissement général de la machine et du moteur d’exécution. Je vois trois niveaux possibles : - **A — modèle large actuel** : couvre aussi l’hôte local, TOCTOU par un processus du même UID, replay, corruption SQLite, concurrence Pacman, etc. C’est robuste, mais clairement surdimensionné pour AURoscope. - **B — périmètre chaîne d’approvisionnement AUR** : traite comme hostiles le PKGBUILD, les fichiers de recette, les sources/upstreams et leurs métadonnées. AURoscope les inspecte, signale des indices compréhensibles et laisse toujours la décision à l’utilisateur. La machine locale, le compte utilisateur, Pacman/Paru/makepkg et les autres processus locaux sont hors modèle de menace. - **C — aucun gate sécurité dédié** : simple à livrer, mais on ne prouve même pas que l’outil analyse sans exécuter la recette ni que ses alertes essentielles restent stables. **Ma recommandation actuelle est B**, avec des gates v1 volontairement courts : 1. tests sur un corpus de recettes bénignes et suspectes couvrant les règles/indices annoncés ; 2. preuve que la phase d’inspection n’exécute ni PKGBUILD ni source du paquet ; 3. tests de restitution : alertes lisibles, provenance de l’indice, erreurs d’analyse explicites, aucune décision automatique ; 4. un E2E Arch jetable confirmant le flux analyse → indices → décision humaine avant installation. Je retirerais des gates v1 les protections contre processus local hostile, inode swap, replay d’approbation, corruption/backup SQLite, concurrence Pacman, PATH/editor, cleanup escape et durcissement général de sudo. On conserve seulement les tests de robustesse nécessaires au fonctionnement de l’application, sans les présenter comme une garantie contre une machine locale compromise. Autrement dit, AURoscope fournit une aide à la revue contre le risque de chaîne d’approvisionnement AUR; ce n’est ni une sandbox, ni un antivirus, ni une frontière de sécurité locale. Cette recommandation reste en discussion et ne vaut pas acceptation de la décision.

mathieu commented

2026-08-30 23:41:22 +00:00

Owner

GO DECISION

hephaistos added

Agent/Hermes

and removed

Agent/Human

labels

2026-08-30 23:45:33 +00:00

hephaistos commented

2026-08-30 23:56:38 +00:00

Author

Owner

Décision D12 consignée et vérifiée.

ADR accepté : ADR-0013 — AUR supply-chain threat model and v1 test gates
commit de décision signé : 7dc5813
tête distante intégrée à la PR de design : af2f0f8
PR existante : #1, ouverte et mergeable

La documentation limite désormais explicitement le modèle de menace aux entrées hostiles de la chaîne d’approvisionnement AUR et fixe les quatre gates v1 acceptés. La machine locale et le compte utilisateur restent hors garantie. Aucun code de production ni plan d’implémentation n’a été créé.

Vérifications : git diff --check, résolution de tous les liens Markdown locaux, signatures Git SSH valides, branches distantes et tête de PR relues via Git/API.

Décision D12 consignée et vérifiée. - ADR accepté : [`ADR-0013 — AUR supply-chain threat model and v1 test gates`](https://git.2027a.net/2027a/auroscope/src/commit/af2f0f8449a280844c498aa7bfeaf0ec242475f4/docs/decisions/0013-aur-supply-chain-threat-model-and-v1-test-gates.md) - commit de décision signé : [`7dc5813`](https://git.2027a.net/2027a/auroscope/commit/7dc5813) - tête distante intégrée à la PR de design : [`af2f0f8`](https://git.2027a.net/2027a/auroscope/commit/af2f0f8449a280844c498aa7bfeaf0ec242475f4) - PR existante : [#1](https://git.2027a.net/2027a/auroscope/pulls/1), ouverte et mergeable La documentation limite désormais explicitement le modèle de menace aux entrées hostiles de la chaîne d’approvisionnement AUR et fixe les quatre gates v1 acceptés. La machine locale et le compte utilisateur restent hors garantie. Aucun code de production ni plan d’implémentation n’a été créé. Vérifications : `git diff --check`, résolution de tous les liens Markdown locaux, signatures Git SSH valides, branches distantes et tête de PR relues via Git/API.

hephaistos closed this issue

2026-08-30 23:57:09 +00:00