Résumé

  • RFC 1408 attribuait VAR=0 et VALUE=1 à l’option Telnet 36. RFC 1571 constata ensuite que l’implémentation BSD de référence employait les deux significations dans l’ordre inverse.
  • Pour survivre à cette double grammaire, RFC 1571 proposa d’observer les formes impossibles, l’ordre des marqueurs, leur nombre et les noms connus. Certaines séquences restaient pourtant indécidables.
  • RFC 1572 conserva la définition écrite mais la plaça sous le nouveau numéro 39, NEW-ENVIRON. Le serveur gardait en outre le choix local d’ignorer, de remplacer ou d’utiliser toute valeur reçue.

Deux lecteurs, une suite d’octets

En janvier 1993, RFC 1408 voulut résoudre un besoin modeste : faire passer des informations d’environnement d’un client Telnet à un serveur au moment d’une connexion. L’option reçut le numéro 36. Sa sous-négociation distinguait IS, SEND et INFO, puis quatre marqueurs : VAR valait zéro, VALUE un, ESC deux et USERVAR trois.

Cette petite grammaire séparait le nom de la valeur, les variables reconnues des noms créés par l’utilisateur, et les octets de contrôle de leur présence littérale dans une chaîne. Elle distinguait aussi une variable absente d’une variable définie mais vide. Sans marqueur VALUE, la variable était indéfinie ; avec VALUE immédiatement suivi d’un nouveau type ou de la fin, elle existait avec une valeur vide.

Le problème n’était donc pas un détail typographique. Si zéro et un s’échangeaient, le découpage même du message changeait. RFC 1571, publié un an plus tard, expliqua que les définitions de RFC 1408 étaient inversées par rapport à l’implémentation BSD. Le texte qualifiait BSD d’implémentation de référence que le RFC devait documenter et de base de nombreuses implémentations existantes.

Cette formulation contemporaine ne fournit aucun recensement chiffré. Elle suffit toutefois à établir l’état qui comptait pour l’interopérabilité : l’option 36 avait déjà deux lectures historiques. Citer son numéro ne disait plus comment un pair interpréterait zéro.

Un transport générique plutôt qu’une option par variable

Les systèmes d’exploitation détenaient des informations de démarrage utiles sur une machine distante. Créer une option Telnet pour chaque nouvelle donnée aurait épaissi le protocole au rythme des besoins locaux. ENVIRON proposait plutôt un conteneur général.

RFC 1408 définissait six noms connus : USER, JOB, ACCT, PRINTER, SYSTEMTYPE et DISPLAY. USERVAR accueillait les paires arbitraires fournies par l’utilisateur. Cette étiquette conservait l’origine de classe de la donnée ; elle ne garantissait ni sa véracité ni son innocuité. Le RFC notait que les implémentations prudentes pourraient se méfier autant des deux classes et laissait les collisions de noms au logiciel local.

L’échange était désactivé par défaut : WONT ENVIRON et DONT ENVIRON. Un côté annonçait avec WILL qu’il acceptait d’émettre ; l’autre, avec DO, qu’il acceptait de recevoir. Seul le côté ayant envoyé DO pouvait demander des variables par SEND. Seul celui ayant envoyé WILL pouvait répondre par IS ou signaler une évolution par INFO.

Cette direction évitait de confondre consentement et résultat. WILL ne prouvait pas qu’un SEND arriverait. SEND ne prouvait pas que la variable existait. IS décrivait une réponse initiale ; INFO, éventuellement spontané, décrivait une modification ultérieure. Aucun des deux ne prouvait l’application de la donnée.

Le serveur ne recevait pas un ordre

La plupart des systèmes ne propageaient l’environnement qu’à la création d’un processus. L’information devait donc souvent arriver tôt, avant l’ouverture de session. Cette proximité avec l’authentification rendait le pouvoir local du serveur essentiel.

RFC 1408 disait expressément que l’hôte récepteur n’était pas obligé d’insérer toutes les variables dans l’environnement. Il pouvait ignorer un nom inconnu, utiliser USER ou ACCT pour une décision de connexion sans les copier dans le processus, ou préférer une source jugée plus précise.

Ainsi, un client pouvait envoyer USERVAR TERM=xterm, mais le serveur pouvait l’écarter si l’option Telnet Terminal-Type avait déjà déterminé le type du terminal. Pour DISPLAY, le document prévoyait une autre règle locale : en cas de contradiction avec l’option X-Display-Location, l’information reçue le plus récemment devait l’emporter.

Le protocole rendait donc les prétentions transportables sans les transformer en autorité. USER était le compte souhaité, pas une identité authentifiée. PRINTER indiquait un emplacement par défaut dont le format n’était même pas normalisé ; il ne démontrait ni accès ni impression. DISPLAY ne prouvait ni connexion X ni fenêtre visible.

La section de sécurité traçait la même frontière. Avant l’authentification, certaines variables pouvaient influencer le programme de connexion. Un mauvais choix risquait de permettre un contournement ou une compromission. RFC 1408 ne relatait pas une attaque précise : il avertissait que l’entrée distante et le pouvoir d’exécution local ne devaient pas être fusionnés.

Les heuristiques lisaient l’histoire dans la forme

Face aux deux dictionnaires de l’option 36, RFC 1571 ne pouvait pas demander au pair une métadonnée qu’il ne transmettait pas. Il exploita les contraintes grammaticales.

Dans un message SEND, seuls VAR et USERVAR étaient licites. Si le client rencontrait ce que son propre dictionnaire nommait VALUE, il pouvait conclure que le serveur avait inversé zéro et un, puis renverser sa lecture pour la suite et pour sa réponse. Si aucun marqueur zéro ou un n’apparaissait, aucune preuve n’était disponible : il fallait supposer l’ordre publié.

Côté serveur, IS ou INFO suivi immédiatement de VAR signalait l’ordre du RFC ; suivi de VALUE, l’ordre inversé. Un début par USERVAR était moins révélateur, car un nom d’utilisateur pouvait légalement être suivi d’un nom ou d’une valeur selon la structure. Le parseur cherchait alors deux marqueurs consécutifs, un marqueur vide, comparait les comptes, puis regardait si les chaînes ressemblaient à des noms connus.

Ce dispositif ne découvrait pas la vérité d’une variable. Il cherchait le dictionnaire historique qui rendait le flux le plus grammatical. Certaines observations étaient fortes parce qu’une lecture produisait une construction interdite ; d’autres restaient probables. Si tous les tests échouaient, le RFC prescrivait encore une hypothèse : considérer le pair conforme au texte publié.

Une implémentation qui ne conserve que la paire décodée efface ce raisonnement. Pour auditer la décision, il faudrait garder les octets, le numéro d’option, la direction, la version du parseur, l’heuristique déclenchée, le dictionnaire retenu et l’ambiguïté résiduelle.

Le numéro 39 ne réécrivit pas le numéro 36

RFC 1572 choisit en janvier 1994 une solution plus propre pour les nouvelles connexions. Il conserva VAR=0 et VALUE=1, mais sous une nouvelle option Telnet : 39, NEW-ENVIRON. Le document expliquait que ce nouveau numéro permettait l’interopérabilité sans ambiguïté.

Corriger seulement la table de l’option 36 aurait créé une nouvelle déclaration sur un état ancien. Le pair n’aurait toujours pas su si le programme distant provenait de BSD ou du texte. Le numéro 39 fit autre chose : sa négociation sélectionnait une grammaire neuve et déterministe, sans prétendre modifier les exécutables déjà installés.

Le registre IANA des options Telnet garde aujourd’hui les deux traces : 36 pour Environment Option, lié à RFC 1408, et 39 pour New Environment Option, lié à RFC 1572. Ce registre atteste l’allocation. Il ne prouve pas qu’un hôte implémente l’une des options, qu’une négociation a réussi ou qu’un processus a reçu une variable.

NEW-ENVIRON ne centralisait pas davantage la décision. Le consentement restait bilatéral, l’échange désactivé par défaut, les sources distinguées et l’application locale. Le sens commun du fil devenait stable ; le devenir de l’entrée demeurait au récepteur.

Une variable décodée restait au milieu de la chaîne

La hiérarchie de preuve commence par une affectation publiée. Un programme émet un octet selon son dictionnaire. Le pair le lit ou infère le dictionnaire à l’aide d’une heuristique. Le parseur produit une paire candidate. Le serveur identifie sa provenance, puis l’ignore, la remplace ou l’accepte. Une procédure de connexion ou de création de processus peut l’utiliser. Une application peut ensuite observer l’environnement. Une action extérieure exige encore sa propre preuve.

Aucun niveau n’acquiert automatiquement l’autorité du suivant. La publication n’a pas reprogrammé BSD. Le décodage n’a pas authentifié USER. La réception n’a pas créé un processus. L’environnement n’a pas exécuté une commande. Le numéro IANA n’a pas constaté un résultat.

Sources

Ces sources établissent la grammaire, le récit contemporain du conflit BSD, les heuristiques, le nouveau numéro et les inscriptions du registre. Elles n’établissent ni implémentation nommée, ni part de déploiement, ni attaque, ni identité, ni connexion acceptée, ni environnement appliqué, ni commande exécutée, ni risque actuel.