Résumé

  • Le micrologiciel 5130 ajoute l’architecture openwrt-hwprobe, destinée au micrologiciel de nouvelle génération sur des sondes matérielles existantes ; le plan trimestriel qualifie néanmoins l’ensemble du chantier OpenWrt d’« en cours ».
  • Le dossier public comporte déjà de vrais contrôles : branche de production, convention de versions, clés publiques propres aux générations, notes de version, aide au diagnostic par sommes de contrôle et version visible dans les fiches de sonde.
  • Ces pièces ne disent pas, à elles seules, quel commit et quelle chaîne OpenWrt ont produit quel artefact signé, pour quel matériel, dans quelle vague et avec quel résultat.
  • Aucun incident, paquet non signé, échec de mise à jour ou résultat de mesure erroné n’est allégué. RIPE NCC devrait publier un manifeste agrégé et conserver un registre protégé au niveau de la sonde.

La version arrive au bout de la chaîne

Lorsque l’interface d’une sonde affiche « 5130 », elle montre un état observé après plusieurs décisions. Du code a été retenu. Une configuration OpenWrt et des dépendances ont été choisies. Un binaire a été produit, signé, autorisé pour un type de matériel, proposé à un appareil puis accepté — ou non — avant que la sonde se reconnecte. La version est donc l’étiquette finale d’une succession d’actes, pas leur preuve cumulée.

La note de version 5130 illustre cette différence. Elle couvre toutes les plateformes, les sondes matérielles, les sondes logicielles et l’intégration continue. Dans la seule partie matérielle, elle annonce l’ajout de openwrt-hwprobe, qui permet un micrologiciel de nouvelle génération sur le matériel existant. Elle décrit aussi le passage d’une base scindée à une base commune, l’affichage de sommes de contrôle pour faciliter le diagnostic des fichiers de mise à jour, la correction d’un défaut de mise à niveau de l’application et la récupération de la configuration réseau statique enregistrée.

Ces modifications ont un même numéro, mais pas une même nature. Certaines portent sur la construction du paquet, d’autres sur le démarrage, l’enregistrement ou les mesures. Une sonde peut être compatible avec l’architecture sans avoir reçu l’artefact. Elle peut avoir reçu l’artefact sans avoir achevé les tests fonctionnels. Elle peut enfin avoir été ramenée à une version antérieure après une alerte. Aucun de ces cas ne contredit l’existence de la version 5130.

Il faut donc lire la version comme une clé de jointure. Pour qu’elle serve de preuve, elle doit conduire vers des identifiants immuables en amont et vers un état de déploiement explicite en aval.

Un plan en cours et du code livré peuvent être vrais ensemble

Le plan trimestriel de RIPE Atlas indique que RIPE NCC cherche à simplifier le processus de micrologiciel et travaille à OpenWRT pour les sondes matérielles. Le statut publié est « en cours ». La formule décrit correctement un programme dont plusieurs étapes peuvent coexister.

La version 5130 rend pourtant une partie du programme tangible : l’architecture existe dans une livraison publique. Il serait erroné d’en conclure que la migration du parc est terminée. Il serait tout aussi erroné de considérer que rien n’a changé tant que la ligne du plan n’est pas marquée « terminé ».

Une politique de livraison sérieuse doit pouvoir dire : architecture fusionnée, paquet de production approuvé, première cohorte éligible, vague commencée, vague observée, ancien chemin encore actif, déploiement suspendu ou version remplacée. Le mot « livré » ne peut pas transporter toutes ces étapes.

Cette granularité protège aussi RIPE NCC contre des conclusions hâtives. Un appareil hors ligne n’est pas nécessairement un échec. Une mise à jour différée peut être une décision prudente. Un retour arrière peut démontrer que le mécanisme de sécurité fonctionne. Sans états distincts, les trois situations risquent d’être comptées comme des anomalies identiques.

La documentation de construction contient déjà une grammaire de contrôle

Le guide BUILD épinglé décrit master comme la branche prête pour la production et précise que le micrologiciel des sondes matérielles en est construit. Il sépare aussi testing, devel et les branches de tickets. Enfin, il réserve en principe à la production les numéros divisibles par dix.

Ces conventions sont utiles. Elles empêchent qu’une branche de développement soit confondue avec une livraison et donnent un sens public aux numéros. Mais le nom master se déplace. Pour reconstruire un binaire ancien, il faut le commit effectivement utilisé. Le guide le reconnaît d’ailleurs : un flux OpenWrt peut viser une branche ou être fixé sur un commit avec ^commit.

Le Makefile OpenWrt épinglé complète le tableau. Il prend la version du fichier VERSION, copie l’arbre source vers l’environnement de compilation et embarque des classes de clés publiques de développement, test et production pour les générations v3, v4 et v5. Le paquet matériel n’est à installer que sur instruction de RIPE NCC.

On voit ici quatre autorités différentes : la maturité du code, l’identité de la livraison, l’authenticité du paquet et la permission opérationnelle. Les réunir sous un numéro pratique est acceptable pour l’interface. Les confondre dans l’audit ne l’est pas.

Un manifeste minimal devrait donc fixer le commit, la version et le SDK OpenWrt, les flux de dépendances, les profils matériels, la configuration de compilation, les empreintes des artefacts, la classe ou l’empreinte de la clé publique de production et le rôle qui a approuvé la livraison. La clé privée n’a évidemment aucune place dans le document public.

La compilation ne s’arrête pas au code de la sonde

Deux binaires peuvent partir du même commit applicatif et diverger si le compilateur, un paquet amont, un flux OpenWrt, un correctif ou une option change. Le commit est donc nécessaire, mais pas suffisant. Le manifeste doit identifier les autres entrées de manière stable et donner l’empreinte de sortie.

Il n’est pas indispensable de promettre qu’un tiers pourra reproduire chaque octet dans n’importe quel environnement. La première obligation est plus modeste : permettre de vérifier que deux artefacts portant la même identité étaient censés être identiques, et qu’un appareil donné n’a pas reçu une variante sans trace.

La note 5130 mentionne elle-même des impressions de sommes de contrôle supplémentaires pour diagnostiquer les fichiers de mise à jour. Ce détail est important. Il montre que l’intégrité et l’identification des fichiers ont une valeur opérationnelle avant même toute exigence éditoriale. Le reçu proposé ne fait qu’étendre cette logique au passage entre construction, signature, autorisation et résultat.

Le registre public peut rester compact. Le registre interne, lui, doit être assez précis pour répondre à une contestation future : quelle empreinte a été proposée, quel appareil était admissible, quelle réponse a été reçue et quel test a suivi ?

Une flotte ne se met pas à jour en un instant

La documentation Gérer votre sonde dit qu’après connexion la sonde passera « très probablement » au micrologiciel le plus récent, puis commencera ses mesures prédéfinies. Elle indique aussi que la page détaillée affiche la version. L’API publique des sondes permet de filtrer sur firmware_version.

Cette visibilité est précieuse, mais « très probablement » n’est pas « simultanément et sans exception ». Des sondes sont hors ligne. Les générations peuvent ne pas partager la même admissibilité. Une vague peut être volontairement limitée. Une sonde peut télécharger, redémarrer, se reconnecter puis échouer à un test spécifique. La version observée ne révèle pas le dénominateur ni la trajectoire.

Rendre publique chaque trajectoire serait une mauvaise solution. L’identité, l’emplacement et l’état d’échec d’une sonde peuvent être sensibles. La bonne architecture comporte deux niveaux.

Le niveau protégé lie l’identifiant de l’appareil, sa génération, les versions avant et après, l’empreinte de l’artefact, la règle d’admissibilité, les heures de tentative et d’accusé, le résultat de vérification, les tests de connexion et de mesure, la classe d’erreur, la nouvelle tentative, l’autorisation de retour arrière et le motif d’exception.

Le niveau public agrège ces états par génération ou cohorte suffisamment large : admissibles, tentées, réussies, différées, échouées et revenues en arrière. Il fixe la fenêtre d’observation, la règle de dénominateur et l’état de la version — active, suspendue, remplacée ou retirée.

Installer n’est pas encore mesurer

Une sonde RIPE Atlas n’est pas un routeur domestique dont la réussite se résume au démarrage. Sa fonction est de produire des mesures. Le test d’acceptation doit donc franchir plusieurs seuils : vérification de l’artefact, démarrage, conservation de l’identité, reconnexion au contrôleur, comportement de l’horloge, puis un ensemble représentatif de DNS, ping, traceroute et fonctions touchées par la livraison.

Le détail exploitable des cibles ou des seuils peut rester protégé. Le public a surtout besoin de la version de la suite, de la règle de réussite et du résultat agrégé. Sans cela, « installé » risque d’être traduit par « apte à mesurer » sans preuve intermédiaire.

Le retour arrière mérite le même traitement. Il ne suffit pas de savoir qu’une ancienne version est réapparue. Le reçu doit dire quel seuil a été franchi, qui pouvait décider, quelle cohorte a été arrêtée et si les mesures produites pendant l’intervalle exigent une annotation. Un retour arrière documenté n’est pas un aveu d’échec ; c’est une capacité de maîtrise.

Le reçu manquant est une jointure, pas un nouveau comité

Le dépôt public de la version 5130, les notes de version, les règles de branche, les profils matériels et la version observable constituent déjà une grande partie du vocabulaire. La proposition n’est pas d’ajouter une cérémonie éditoriale au travail des ingénieurs. Elle consiste à générer automatiquement un manifeste signé à partir des systèmes de compilation et de déploiement.

La couche publique pourrait contenir : numéro de version, commit immuable, identités OpenWrt et dépendances, profils cibles, empreintes d’artefact et de manifeste, classe de clé de production, rôle approbateur, cohorte et dénominateur, fenêtre, états agrégés, suite de tests, seuil de retour, exceptions, version de remplacement et historique de correction.

Rien n’oblige à publier les secrets, les hôtes ou une carte des erreurs. Rien ne justifie non plus qu’un numéro soit le seul souvenir durable d’une livraison. Une chaîne plus rapide et plus commune augmente la valeur d’une trace automatique : si un défaut partagé peut voyager plus loin, la preuve de ce qui a voyagé doit devenir plus facile à établir.

Sources