2027a/auroscope

Watch

Fork 0

[Decision D4] Fixer la garantie anti-TOCTOU et le timing du garde #5

New issue

Closed

opened 2026-08-30 20:42:56 +00:00 by hephaistos · 6 comments

hephaistos commented

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

Owner

MODE: DECISION

Statut

Proposé — amendement potentiel à la spécification. Ne pas fermer avant ton go explicite.

Question

La spécification dit que PreBuildCommand vérifie « immédiatement avant chaque build ». Paru 2.1 ne fournit pas ce timing. Quelle garantie voulons-nous réellement contractualiser ?

Fait vérifié

Paru télécharge les recettes, appelle tous les PreBuildCommand, effectue ensuite d’autres opérations, puis lance les builds individuels. Avec --skipreview, aucune édition Paru de la recette n’a lieu après le garde, mais le hook n’est pas littéralement adjacent à chaque makepkg.

Options

A — Amender la garantie au vrai périmètre de sécurité

Le hook est la dernière vérification complète des recettes avant toute exécution makepkg/PKGBUILD. Le manifeste est recalculé avant et après la réclamation atomique; Paru peut ensuite installer des dépendances officielles avant le build.

Pour : correspond exactement au comportement prouvé; aucun code hostile de recette ne tourne dans l’intervalle.
Contre : modifie explicitement la phrase actuelle; une course par autre processus du même UID reste possible.

B — Attendre/modifier Paru pour un hook par build

Pour : conserve la formulation littérale.
Contre : bloque la production sur un changement upstream; ne supprime pas la course same-UID après retour.

C — Interposer un proxy makepkg AURoscope

Pour : rehash juste avant chaque invocation makepkg.
Contre : beaucoup plus large : appels multiples, pkgver() VCS, chroot, mutations légitimes/hostiles difficiles à distinguer.

Recommandation

Option A, comme amendement assumé. Le modèle de menace exclut la compromission du compte utilisateur et documente la course same-UID.

Cache

Une approbation de recette n’authentifie pas un binaire déjà en cache. Rebuild par défaut; réutilisation seulement si le SHA-256 de l’artefact est lié à un build réussi de l’identité exacte.

Réponse attendue

Choisis A/B/C. Après ta réponse, je formule précisément la garantie; ADR et fermeture seulement après ton go.

Documentation

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é — amendement potentiel à la spécification.** Ne pas fermer avant ton **go explicite**. ## Question La spécification dit que `PreBuildCommand` vérifie « immédiatement avant chaque build ». Paru 2.1 ne fournit pas ce timing. Quelle garantie voulons-nous réellement contractualiser ? ## Fait vérifié Paru télécharge les recettes, appelle tous les `PreBuildCommand`, effectue ensuite d’autres opérations, puis lance les builds individuels. Avec `--skipreview`, aucune édition Paru de la recette n’a lieu après le garde, mais le hook n’est pas littéralement adjacent à chaque makepkg. ## Options ### A — Amender la garantie au vrai périmètre de sécurité Le hook est **la dernière vérification complète des recettes avant toute exécution makepkg/PKGBUILD**. Le manifeste est recalculé avant et après la réclamation atomique; Paru peut ensuite installer des dépendances officielles avant le build. **Pour :** correspond exactement au comportement prouvé; aucun code hostile de recette ne tourne dans l’intervalle. **Contre :** modifie explicitement la phrase actuelle; une course par autre processus du même UID reste possible. ### B — Attendre/modifier Paru pour un hook par build **Pour :** conserve la formulation littérale. **Contre :** bloque la production sur un changement upstream; ne supprime pas la course same-UID après retour. ### C — Interposer un proxy makepkg AURoscope **Pour :** rehash juste avant chaque invocation makepkg. **Contre :** beaucoup plus large : appels multiples, `pkgver()` VCS, chroot, mutations légitimes/hostiles difficiles à distinguer. ## Recommandation **Option A**, comme amendement assumé. Le modèle de menace exclut la compromission du compte utilisateur et documente la course same-UID. ## Cache Une approbation de recette n’authentifie pas un binaire déjà en cache. Rebuild par défaut; réutilisation seulement si le SHA-256 de l’artefact est lié à un build réussi de l’identité exacte. ## Réponse attendue Choisis A/B/C. Après ta réponse, je formule précisément la garantie; ADR et fermeture seulement après ton **go**. ## Documentation - https://git.2027a.net/2027a/auroscope/src/branch/design/technical-contracts/docs/architecture/design-proposals.md - https://git.2027a.net/2027a/auroscope/src/branch/design/technical-contracts/docs/dependency-notes/paru-contract.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:46 +00:00

mathieu commented

2026-08-30 21:06:28 +00:00

Owner

A priori, A. Mais là encore, je ne suis pas certain de bien comprendre le problème et suspecte un manque de simplicité. Dans le hook z on a simplement besoin de valider l'identité du PKGBUILD entre l'audit et l'installation? Est-ce que quelque chose m'échappe?

hephaistos commented

2026-08-30 23:19:35 +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:21:47 +00:00

Author

Owner

Oui — l’objectif simple est bien de vérifier que la recette exécutée est exactement celle qui a été auditée. La nuance est double :

L’identité ne doit pas couvrir seulement PKGBUILD, mais tout le manifeste de recette pertinent à l’audit (notamment les fichiers locaux sourcés ou utilisés par le build).
Avec Paru 2.1, le hook ne s’exécute pas juste avant chaque makepkg : il vérifie toutes les recettes, puis Paru peut encore installer des dépendances officielles avant de lancer les builds. Dire « immédiatement avant chaque build » promet donc un timing que Paru ne fournit pas.

La garantie simple que je recommande reste A :

Après la phase de revue de Paru et avant toute première exécution de code provenant d’une recette, AURoscope recalcule l’identité complète de chaque recette et exige qu’elle corresponde à l’identité auditée. Toute différence fait échouer l’opération.

Ainsi, les opérations internes de Paru entre le garde et makepkg ne sont pas un problème tant qu’elles n’exécutent ni ne modifient une recette. La seule limite résiduelle est qu’un autre processus du même utilisateur pourrait modifier les fichiers après le retour du hook; éliminer cette course exigerait une isolation ou une interposition beaucoup plus lourde, sans bénéfice proportionné dans le modèle de menace actuel.

Donc non, il ne manque pas une mécanique complexe : il faut surtout corriger la formulation du contrat pour ne pas confondre « dernière validation avant toute exécution de recette » avec « validation adjacente à chaque build ». Ma recommandation courante est A avec cette formulation, et la décision reste en discussion tant qu’il n’y a pas de signal distinct GO DECISION.

Oui — l’objectif simple est bien de vérifier que **la recette exécutée est exactement celle qui a été auditée**. La nuance est double : 1. L’identité ne doit pas couvrir seulement `PKGBUILD`, mais tout le manifeste de recette pertinent à l’audit (notamment les fichiers locaux sourcés ou utilisés par le build). 2. Avec Paru 2.1, le hook ne s’exécute pas juste avant chaque `makepkg` : il vérifie toutes les recettes, puis Paru peut encore installer des dépendances officielles avant de lancer les builds. Dire « immédiatement avant chaque build » promet donc un timing que Paru ne fournit pas. La garantie simple que je recommande reste **A** : > Après la phase de revue de Paru et avant toute première exécution de code provenant d’une recette, AURoscope recalcule l’identité complète de chaque recette et exige qu’elle corresponde à l’identité auditée. Toute différence fait échouer l’opération. Ainsi, les opérations internes de Paru entre le garde et `makepkg` ne sont pas un problème tant qu’elles n’exécutent ni ne modifient une recette. La seule limite résiduelle est qu’un autre processus du même utilisateur pourrait modifier les fichiers après le retour du hook; éliminer cette course exigerait une isolation ou une interposition beaucoup plus lourde, sans bénéfice proportionné dans le modèle de menace actuel. Donc non, il ne manque pas une mécanique complexe : il faut surtout **corriger la formulation du contrat** pour ne pas confondre « dernière validation avant toute exécution de recette » avec « validation adjacente à chaque build ». Ma recommandation courante est A avec cette formulation, et la décision reste en discussion tant qu’il n’y a pas de signal distinct `GO DECISION`.

mathieu commented

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

Owner

GO DECISION

hephaistos added

Agent/Hermes

and removed

Agent/Human

labels

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

hephaistos commented

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

Author

Owner

Convention de finalisation concurrente : utilise le numéro du ticket comme numéro ADR sur quatre chiffres (#N → NNNN-*.md). Ne choisis pas « le prochain numéro libre » et ne renumérote aucun ADR; cette règle évite les collisions entre décisions validées en parallèle.

Convention de finalisation concurrente : utilise le numéro du ticket comme numéro ADR sur quatre chiffres (`#N` → `NNNN-*.md`). Ne choisis pas « le prochain numéro libre » et ne renumérote aucun ADR; cette règle évite les collisions entre décisions validées en parallèle.

hephaistos commented

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

Author

Owner

Décision D4 consignée et vérifiée :

ADR accepté : 121ed01b3e/docs/decisions/0005-recipe-identity-guard-boundary.md
commit signé : 121ed01b3e
PR de design mise à jour : #1

La spécification décrit désormais le vrai contrat : dernière vérification complète de l’identité des recettes après la revue AURoscope et avant toute exécution de code de recette, avec --skipreview; elle ne prétend plus que le hook est adjacent à chaque build. La course résiduelle après le garde pour un autre processus du même UID reste explicitement documentée.

Validation : git diff --check; commit local et tête distante du PR relus à 121ed01b3ef9f11c895b2643b0ac6cb1bc82ddb3, signature SSH valide pour hephaistos@ecl.400iso.net. Aucun code de production ni plan d’implémentation ajouté.

Décision D4 consignée et vérifiée : - ADR accepté : https://git.2027a.net/2027a/auroscope/src/commit/121ed01b3ef9f11c895b2643b0ac6cb1bc82ddb3/docs/decisions/0005-recipe-identity-guard-boundary.md - commit signé : https://git.2027a.net/2027a/auroscope/commit/121ed01b3ef9f11c895b2643b0ac6cb1bc82ddb3 - PR de design mise à jour : https://git.2027a.net/2027a/auroscope/pulls/1 La spécification décrit désormais le vrai contrat : dernière vérification complète de l’identité des recettes après la revue AURoscope et avant toute exécution de code de recette, avec `--skipreview`; elle ne prétend plus que le hook est adjacent à chaque build. La course résiduelle après le garde pour un autre processus du même UID reste explicitement documentée. Validation : `git diff --check`; commit local et tête distante du PR relus à `121ed01b3ef9f11c895b2643b0ac6cb1bc82ddb3`, signature SSH valide pour `hephaistos@ecl.400iso.net`. Aucun code de production ni plan d’implémentation ajouté.

hephaistos closed this issue

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