2027a/auroscope

Watch

Fork 0

[Decision D9] Définir le protocole d’approbation one-shot #10

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 ≠ approbation finale; clôture après ton go explicite.

Question

À quoi une approbation humaine doit-elle être liée, comment est-elle transmise au garde et quand expire-t-elle ?

Identité proposée

Transaction, source/namespace/pkgbase, commit et tree Git, manifeste canonique, hashes/modes/types de chaque fichier, inspection, décision humaine, device+inode workspace et expiration. Le commit identifie; il ne mesure pas le risque.

Options de handoff

Bearer token en environnement

Simple, mais hérité par les subprocessus. Rejeté.

Fichier secret one-shot

Réduit certains replays, mais ajoute un secret sans contrer un attaquant same-UID.

ID de transaction non secret + liaison SQLite/processus/workspace

Recommandé. Paru reçoit un config privé dont le hook fixe exécute exec /usr/bin/auroscope guard --transaction <id>. Le garde vérifie parent Paru PID/start-time/exe/UID, workspace et manifeste.

Cycle

armed → claimed → consumed, ou invalidated|expired. Réclamation atomique BEGIN IMMEDIATE; manifeste complet calculé avant et après claim. Tous les états terminaux invalident les restes. Expiration proposée : 30 min, maximum configurable 2 h.

Autorité humaine

Une inspection partial ou failed peut encore recevoir approve si limitations/erreurs sont visibles et enregistrées. L’échec n’est ni veto autonome ni approbation silencieuse.

Limite

Un autre processus du même UID peut toujours tenter une course après le garde. Ce n’est pas une garantie contre un compte utilisateur compromis.

Réponse attendue

Accepte/amende le binding, les transitions ou l’expiration. ADR/clôture seulement 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 ≠ approbation finale; clôture après ton **go explicite**. ## Question À quoi une approbation humaine doit-elle être liée, comment est-elle transmise au garde et quand expire-t-elle ? ## Identité proposée Transaction, source/namespace/pkgbase, commit et tree Git, manifeste canonique, hashes/modes/types de chaque fichier, inspection, décision humaine, device+inode workspace et expiration. Le commit identifie; il ne mesure pas le risque. ## Options de handoff ### Bearer token en environnement Simple, mais hérité par les subprocessus. Rejeté. ### Fichier secret one-shot Réduit certains replays, mais ajoute un secret sans contrer un attaquant same-UID. ### ID de transaction non secret + liaison SQLite/processus/workspace **Recommandé.** Paru reçoit un config privé dont le hook fixe exécute `exec /usr/bin/auroscope guard --transaction <id>`. Le garde vérifie parent Paru PID/start-time/exe/UID, workspace et manifeste. ## Cycle `armed → claimed → consumed`, ou `invalidated|expired`. Réclamation atomique `BEGIN IMMEDIATE`; manifeste complet calculé avant et après claim. Tous les états terminaux invalident les restes. Expiration proposée : 30 min, maximum configurable 2 h. ## Autorité humaine Une inspection `partial` ou `failed` peut encore recevoir `approve` si limitations/erreurs sont visibles et enregistrées. L’échec n’est ni veto autonome ni approbation silencieuse. ## Limite Un autre processus du même UID peut toujours tenter une course après le garde. Ce n’est pas une garantie contre un compte utilisateur compromis. ## Réponse attendue Accepte/amende le binding, les transitions ou l’expiration. ADR/clôture seulement 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:48 +00:00

mathieu commented

2026-08-30 21:20:17 +00:00

Owner

Je ne suis pas sur de comprendre, en particulier ce que tu appelles l'identité. Est-ce que le PKGBUILD ferait l'affaire?

hephaistos commented

2026-08-30 23:19:37 +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:24 +00:00

Author

Owner

Par « identité », je ne parle pas de l’identité d’une personne. Je parle de l’empreinte exacte de ce que tu as inspecté et approuvé : il faut pouvoir prouver que le garde autorise bien cette même recette, sans substitution entre l’inspection et l’installation.

Le PKGBUILD seul serait un repère simple, mais il est trop étroit :

il peut référencer des fichiers voisins (.patch, .install, etc.) dont le contenu change sans modifier le PKGBUILD;
le même texte peut exister pour deux sources ou deux pkgbase différents;
il ne décrit pas les types et modes des fichiers, ni un éventuel lien symbolique;
il ne garantit pas que le workspace exécuté est encore celui qui a été inspecté.

Je vois donc trois niveaux :

Hash du PKGBUILD seulement — très lisible, mais insuffisant pour autoriser l’exécution.
Commit/tree Git seulement — couvre bien les fichiers suivis, mais pas à lui seul un workspace sale, des fichiers non suivis pertinents ou une substitution locale.
Manifeste canonique complet + commit/tree + contexte d’exécution — recommandé. Le manifeste contient le PKGBUILD et tous les fichiers de recette pertinents avec chemin, hash, mode et type. Le garde le recalcule sur disque et le compare à celui inspecté. La transaction le lie ensuite au bon source/namespace/pkgbase, au workspace et au processus Paru attendu.

Pour garder l’interface simple, on peut afficher un unique recipe_digest : une empreinte calculée sur ce manifeste complet. Le détail reste enregistré pour expliquer exactement ce qui a été approuvé. Autrement dit, le PKGBUILD fait partie de l’identité, mais ne suffit pas à lui seul.

Ma recommandation actuelle reste donc : ID de transaction non secret, état one-shot en SQLite, approbation liée au manifeste canonique complet et à l’inspection, claim atomique, vérification avant/après claim, expiration par défaut de 30 minutes avec plafond configurable de 2 heures. Cette réponse précise la proposition; elle ne vaut pas acceptation de la décision.

Par « identité », je ne parle pas de l’identité d’une personne. Je parle de **l’empreinte exacte de ce que tu as inspecté et approuvé** : il faut pouvoir prouver que le garde autorise bien cette même recette, sans substitution entre l’inspection et l’installation. Le `PKGBUILD` seul serait un repère simple, mais il est trop étroit : - il peut référencer des fichiers voisins (`.patch`, `.install`, etc.) dont le contenu change sans modifier le `PKGBUILD`; - le même texte peut exister pour deux sources ou deux `pkgbase` différents; - il ne décrit pas les types et modes des fichiers, ni un éventuel lien symbolique; - il ne garantit pas que le workspace exécuté est encore celui qui a été inspecté. Je vois donc trois niveaux : 1. **Hash du `PKGBUILD` seulement** — très lisible, mais insuffisant pour autoriser l’exécution. 2. **Commit/tree Git seulement** — couvre bien les fichiers suivis, mais pas à lui seul un workspace sale, des fichiers non suivis pertinents ou une substitution locale. 3. **Manifeste canonique complet + commit/tree + contexte d’exécution** — recommandé. Le manifeste contient le `PKGBUILD` et tous les fichiers de recette pertinents avec chemin, hash, mode et type. Le garde le recalcule sur disque et le compare à celui inspecté. La transaction le lie ensuite au bon `source/namespace/pkgbase`, au workspace et au processus Paru attendu. Pour garder l’interface simple, on peut afficher un unique `recipe_digest` : une empreinte calculée sur ce manifeste complet. Le détail reste enregistré pour expliquer exactement ce qui a été approuvé. Autrement dit, **le `PKGBUILD` fait partie de l’identité, mais ne suffit pas à lui seul**. Ma recommandation actuelle reste donc : ID de transaction non secret, état one-shot en SQLite, approbation liée au manifeste canonique complet et à l’inspection, claim atomique, vérification avant/après claim, expiration par défaut de 30 minutes avec plafond configurable de 2 heures. Cette réponse précise la proposition; elle ne vaut pas acceptation de la décision.

mathieu commented

2026-08-30 23:35:03 +00:00

Owner

GO DECISION

hephaistos added

Agent/Hermes

and removed

Agent/Human

labels

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

hephaistos commented

2026-08-30 23:51:04 +00:00

Author

Owner

Décision D9 consignée et vérifiée, sans code de production ni plan d’implémentation.

ADR accepté : ADR-0010
Commit de décision signé : 5f0635b
Intégration distante signée : 6fe245c
PR de design mise à jour : #1, ouverte et fusionnable, tête vérifiée sur 6fe245c6487de4607768cad134708912966721f4

Validation documentaire : git diff --check; branche décisionnelle et branche design/technical-contracts relues à la même tête distante.

Décision D9 consignée et vérifiée, sans code de production ni plan d’implémentation. - ADR accepté : [`ADR-0010`](https://git.2027a.net/2027a/auroscope/src/commit/6fe245c6487de4607768cad134708912966721f4/docs/decisions/0010-one-shot-approval-protocol.md) - Commit de décision signé : [`5f0635b`](https://git.2027a.net/2027a/auroscope/commit/5f0635ba6cc814bfaed1db8e4101dbc617010ead) - Intégration distante signée : [`6fe245c`](https://git.2027a.net/2027a/auroscope/commit/6fe245c6487de4607768cad134708912966721f4) - PR de design mise à jour : [#1](https://git.2027a.net/2027a/auroscope/pulls/1), ouverte et fusionnable, tête vérifiée sur `6fe245c6487de4607768cad134708912966721f4` Validation documentaire : `git diff --check`; branche décisionnelle et branche `design/technical-contracts` relues à la même tête distante.

hephaistos closed this issue

2026-08-30 23:51:31 +00:00