2027a/auroscope

Watch

Fork 0

[Decision D13] Traiter les builds locaux et dépôts PKGBUILD en v1 #14

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é. Ticket ouvert jusqu’au go explicite.

Question

Que doit faire AURoscope avec -B, -U sans cible, les cibles locales ./... et les dépôts PKGBUILD configurés ?

Problème critique vérifié

Paru peut appeler makepkg --printsrcinfo pendant la construction/lecture d’un dépôt PKGBUILD, avant PreBuildCommand. makepkg --printsrcinfo source le PKGBUILD; une recette hostile peut donc exécuter avant le garde. handle_sync spécialise aussi les cibles commençant par ./ avant le flux normal.

Un simple --mode=aur,repo n’est pas suffisant : Paru OR les modes et un PkgbuildsOnly de config peut survivre. Le spike sûr injecte des flags finaux qui remettent d’abord le mode à zéro logique :

repo-only → --repo;
AUR-only, dont -Sua → --aur;
combiné/default → --repo --mode=aur.

Avec config hostile PkgbuildsOnly + dépôt GenerateSrcinfo, le marqueur est resté absent sous les flags combinés prouvés.

Options

A — Rejeter en v1

Refuser avant de lancer Paru : -B, -U sans cible, chemins locaux (./, ../, absolus, file:), modes contenant pkgbuilds/p; tout record PKGBUILD inattendu est fatal. Les modes repo/AUR permis sont normalisés avec flags finaux trusted.

Pour : aucune fausse promesse; périmètre AUR sûr.
Contre : AURoscope ne préserve pas encore toutes les commandes Paru.

B — Pass-through avec avertissement

Pour : compatibilité.
Contre : l’entrée principale « sécurité » laisserait exécuter hors garde; UX trompeuse.

C — Concevoir un support local sûr maintenant

Pour : couverture complète.
Contre : requiert un parseur/résolveur ou sandbox/proxy supplémentaire; élargit fortement v1.

Recommandation

Option A. Créer plus tard une décision dédiée si le besoin local devient concret.

Réponse attendue

Choisis A/B/C ou précise les exceptions. ADR/clôture 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é.** Ticket ouvert jusqu’au **go explicite**. ## Question Que doit faire AURoscope avec `-B`, `-U` sans cible, les cibles locales `./...` et les dépôts PKGBUILD configurés ? ## Problème critique vérifié Paru peut appeler `makepkg --printsrcinfo` pendant la construction/lecture d’un dépôt PKGBUILD, **avant** `PreBuildCommand`. `makepkg --printsrcinfo` source le PKGBUILD; une recette hostile peut donc exécuter avant le garde. `handle_sync` spécialise aussi les cibles commençant par `./` avant le flux normal. Un simple `--mode=aur,repo` n’est pas suffisant : Paru OR les modes et un `PkgbuildsOnly` de config peut survivre. Le spike sûr injecte des flags finaux qui remettent d’abord le mode à zéro logique : - repo-only → `--repo`; - AUR-only, dont `-Sua` → `--aur`; - combiné/default → `--repo --mode=aur`. Avec config hostile `PkgbuildsOnly` + dépôt `GenerateSrcinfo`, le marqueur est resté absent sous les flags combinés prouvés. ## Options ### A — Rejeter en v1 Refuser avant de lancer Paru : `-B`, `-U` sans cible, chemins locaux (`./`, `../`, absolus, `file:`), modes contenant `pkgbuilds/p`; tout record PKGBUILD inattendu est fatal. Les modes repo/AUR permis sont normalisés avec flags finaux trusted. **Pour :** aucune fausse promesse; périmètre AUR sûr. **Contre :** AURoscope ne préserve pas encore toutes les commandes Paru. ### B — Pass-through avec avertissement **Pour :** compatibilité. **Contre :** l’entrée principale « sécurité » laisserait exécuter hors garde; UX trompeuse. ### C — Concevoir un support local sûr maintenant **Pour :** couverture complète. **Contre :** requiert un parseur/résolveur ou sandbox/proxy supplémentaire; élargit fortement v1. ## Recommandation **Option A.** Créer plus tard une décision dédiée si le besoin local devient concret. ## Réponse attendue Choisis A/B/C ou précise les exceptions. 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 - 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:49 +00:00

mathieu commented

2026-08-30 21:53:08 +00:00

Owner

Pas entièrement sur de comprendre. S'agit il de savoir comment traîter des fonctions avancées de paru pour des dépôts personnels/ad-hoc et des paquets locaux?

Si c'est bien ça, ça n'est pas nécessaire. En v1, on veut uniquement auditer les paquets aur

Pas entièrement sur de comprendre. S'agit il de savoir comment traîter des fonctions avancées de paru pour des dépôts personnels/ad-hoc et des paquets locaux? Si c'est bien ça, ça n'est pas nécessaire. En v1, on veut uniquement auditer les paquets aur

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:23:59 +00:00

Author

Owner

Oui, c’est exactement ça. Le ticket vise les fonctions avancées de Paru qui lisent ou construisent des PKGBUILD locaux/ad hoc : -B, -U sans cible, les chemins ./... et les dépôts PKGBUILD configurés. Il ne faut pas confondre ces derniers avec les dépôts binaires officiels d’Arch.

Le point de sécurité est que Paru peut sourcer un tel PKGBUILD avant que notre garde soit installé. Un simple pass-through avec avertissement (B) serait donc trompeur; concevoir maintenant un support local réellement sûr (C) demanderait une isolation ou une résolution supplémentaire disproportionnée pour la v1.

Puisque la v1 doit uniquement auditer les paquets AUR, ma recommandation concrète reste A : refuser explicitement ces entrées locales avant de lancer Paru, avec un message clair « hors périmètre v1 », et ne pas développer de support local/sandbox pour l’instant. Les flux AUR supportés restent le seul périmètre d’audit; un besoin local futur ferait l’objet d’une décision séparée.

Cela précise la proposition, sans encore l’accepter : le ticket reste en discussion jusqu’au signal exact GO DECISION.

Oui, c’est exactement ça. Le ticket vise les fonctions avancées de Paru qui lisent ou construisent des PKGBUILD locaux/ad hoc : `-B`, `-U` sans cible, les chemins `./...` et les dépôts PKGBUILD configurés. Il ne faut pas confondre ces derniers avec les dépôts binaires officiels d’Arch. Le point de sécurité est que Paru peut sourcer un tel PKGBUILD avant que notre garde soit installé. Un simple pass-through avec avertissement (B) serait donc trompeur; concevoir maintenant un support local réellement sûr (C) demanderait une isolation ou une résolution supplémentaire disproportionnée pour la v1. Puisque la v1 doit uniquement auditer les paquets AUR, ma recommandation concrète reste **A** : refuser explicitement ces entrées locales avant de lancer Paru, avec un message clair « hors périmètre v1 », et ne pas développer de support local/sandbox pour l’instant. Les flux AUR supportés restent le seul périmètre d’audit; un besoin local futur ferait l’objet d’une décision séparée. Cela précise la proposition, sans encore l’accepter : le ticket reste en discussion jusqu’au signal exact `GO DECISION`.

mathieu commented

2026-08-30 23:42:17 +00:00

Owner

GO DECISION

hephaistos added

Agent/Hermes

and removed

Agent/Human

labels

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

hephaistos commented

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

Author

Owner

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

ADR accepté : ADR-0014 — Reject local PKGBUILD inputs in v1
Commit signé : 55af333
PR de design mise à jour : #1
Vérification : git diff --check; branche décisionnelle et tête de la PR relues à 55af3339b69a9da0ccbabca978553ed2203f113a; PR ouverte et fusionnable.

La décision limite la v1 aux recettes AUR : builds locaux, cibles locales et dépôts PKGBUILD sont refusés avant Paru. Aucun code de production ni plan d’implémentation n’a été créé.

Décision D13 consignée et vérifiée. - ADR accepté : [`ADR-0014 — Reject local PKGBUILD inputs in v1`](https://git.2027a.net/2027a/auroscope/src/commit/55af3339b69a9da0ccbabca978553ed2203f113a/docs/decisions/0014-reject-local-pkgbuild-inputs-in-v1.md) - Commit signé : [`55af333`](https://git.2027a.net/2027a/auroscope/commit/55af3339b69a9da0ccbabca978553ed2203f113a) - PR de design mise à jour : [#1](https://git.2027a.net/2027a/auroscope/pulls/1) - Vérification : `git diff --check`; branche décisionnelle et tête de la PR relues à `55af3339b69a9da0ccbabca978553ed2203f113a`; PR ouverte et fusionnable. La décision limite la v1 aux recettes AUR : builds locaux, cibles locales et dépôts PKGBUILD sont refusés avant Paru. Aucun code de production ni plan d’implémentation n’a été créé.

hephaistos closed this issue

2026-08-30 23:50:01 +00:00