Instruction — l’applicateur AirCom des entitlements

Objet. AirCom est l’une des deux familles d’entitlements encore sans applicateur (avec les périphériques). Depuis la décision d’option B du 2026-08-10, tout octroi qui l’invoque est refusé — un mur assumé, « visible et daté », qui tombera quand l’applicateur existera.

Cette note instruit ce qu’il faudrait pour le faire tomber. Elle ne décide pas.

1. Ce qui existe déjà, et qui est plus qu’on ne croit

Le point d’accroche est prévu, écrit et commenté dans air-com :

• un prédicat d’entitlement (demandeur, service) -> autorisé, stocké par le registry ;
• les refus correspondants : LookupError::Denied, RegisterError::Denied ;
• et le commentaire du type Requester dit exactement où l’on va : « Dans le vrai air-registry (couche 5), elle dérive des entitlements signés (ADR-010) / SO_PEERCRED du pair ; ici, un simple credential opaque suffit à piloter le prédicat. »

Autrement dit : la place de l’applicateur est réservée, et son contrat est déjà exprimé.

2. Ce qui manque, et c’est plus lourd que le branchement

Ce dernier point est le plus déterminant, et il est facile à manquer : il n’existe aujourd’hui aucun destinataire pour une capability AirCom. Brancher l’octroi sur le prédicat donnerait un applicateur qui n’applique à personne.

3. Le découpage est déjà écrit dans la spec

docs/specs/layer-2/air-com.md §0.8 sépare deux mécanismes, et cette séparation est la clé de l’instruction :

1. La distribution initiale — air-launchd remet à chaque service son fd de capability par SCM_RIGHTS, selon les entitlements signés. C’est ce qui incarne « pas d’autorité ambiante » : un service ne trouve pas ses pairs, il les reçoit.
2. La découverte ultérieure — lookup nommé auprès d’air-registry (couche 5), qui rend un fd de connexion.

Le premier vit en couche 2, où air-launchd existe déjà et sait remettre des descripteurs (inherit_fd, éprouvé par le canal de lancement). Le second demande une crate de couche 5 qui n’existe pas.

4. Les trois voies possibles, en concret

Note de nommage. Ces voies s’appellent ici ATTENDRE, DISTRIBUER et REGISTRY — et non « A / B / C ». La décision du 2026-08-10 sur les enveloppes portait déjà un « option B », et réemployer les mêmes lettres pour un autre sujet rendait les deux illisibles.

Voie 1 — ATTENDRE (recommandée)

Ce que je fais concrètement : rien dans le code. Je laisse la famille AirCom refusée par l’enveloppe, et je referme cette instruction en la datant.

Ce que ça produit : aucun changement. Une application qui demanderait un entitlement AirCom continue d’être refusée au lancement, avec le motif OutsideEnvelope au journal.

Ce que ça coûte : rien aujourd’hui — il n’existe aucun service AirCom à joindre. Le refus ne prive personne de quoi que ce soit.

Ce qui reste après : le mur, tel quel. Il tombera le jour où l’une des deux autres voies sera prise.

Voie 2 — DISTRIBUER : le fd de capability initial, sans registry

Ce que je fais concrètement, dans air-launchd (couche 2) :

1. Un type qui dit quel service reçoit quel fd — dérivé de Entitlements.aircom de l’octroi, comme syscall_categories_for dérive déjà les catégories seccomp.
2. À l’exec, remettre ces descripteurs à l’enfant. Le mécanisme existe déjà : AirCommand::inherit_fd (additif couche 1 de #631), que le canal de lancement emploie depuis le temps 1.
3. Ouvrir la famille aircom dans l’enveloppe, comme le réseau vient de l’être : le plafond dirait quels services l’image tolère qu’on joigne.
4. Les tests : un octroi qui nomme air.notify reçoit un fd, un octroi qui ne le nomme pas n’en reçoit aucun, un service hors plafond est refusé.

Ce que ça produit : la moitié de §0.8 qui porte la doctrine — « un service ne trouve pas ses pairs, il les reçoit ». C’est ce qui incarne POLA strict.

Ce que ça coûte : deux ou trois jours d’après l’existant. Et surtout un risque nommé : aucun service ne recevrait ces fd, donc le code ne serait traversé que par ses tests. Le dépôt a déjà payé ce prix — du code qu’aucun usage réel n’emprunte vieillit mal, et ses tests finissent par prouver qu’il compile plutôt qu’il fonctionne.

Ce qui reste après : la découverte (lookup par nom) manque toujours. Une application ne peut joindre que ce qu’on lui a remis au démarrage — ce qui est volontairement le cas nominal, mais ne couvre pas tout.

Voie 3 — REGISTRY : la crate air-registry (couche 5)

Ce que je fais concrètement : j’écris la crate qui n’existe pas — table de services, lookup par nom rendant un fd de connexion, register réservé aux services habilités, et le prédicat d’entitlement alimenté par les octrois. Le mock d’air-com sert de contrat de référence ; il est écrit pour ça.

Ce que ça produit : AirCom pleinement utilisable, et l’applicateur d’entitlements vient avec.

Ce que ça coûte : c’est un chantier d’ADR-001, pas d’ADR-150 — statut « en-cours, chantier ouvert ». Sans rapport de taille avec les deux autres voies : une crate de couche 5, sa spec, ses tests, son intégration. Il mérite sa propre instruction et son propre ordonnancement, pas d’être avalé par un incrément d’ADR-150.

Ce qui reste après : rien de bloqué côté ADR-150.

Ce qui changerait la réponse

Un premier service AirCom réel — le livrable « deux exécutables qui discutent sur AirCom » que le projet porte déjà. Il donnerait un destinataire, et rendrait la voie DISTRIBUER immédiatement utile au lieu d’être du code sans usage.

C’est pourquoi je recommande ATTENDRE : non par prudence, mais parce que les deux autres voies produiraient aujourd’hui du code que rien ne traverse.

6. Questions au BDFL

1. ATTENDRE, DISTRIBUER ou REGISTRY ?

   Recommandation : ATTENDRE — le mur ne coûte rien tant qu’aucun service n’existe, et le lever sans destinataire produirait précisément la « promesse écrite dans un fichier » que la décision du 2026-08-10 a refusée.

2. Faut-il plutôt lancer le premier service AirCom (« deux exécutables qui discutent ») ? C’est ce qui donnerait un destinataire, et rendrait DISTRIBUER utile tout de suite.

3. Si REGISTRY : c’est un chantier d’ADR-001, pas d’ADR-150. L’ouvrir maintenant, ou après le premier service ?

Licence du document : MPL 2.0