Résumé

  • Le guide publié par LACNIC le 10 août télécharge fort-1.7.0.experimental.tar.gz, le décompresse, le compile et exécute sudo make install sous Ubuntu Server 26.04 sans vérifier de somme de contrôle ni de signature détachée.
  • Le tarball, son fichier .asc et fort.keyring avaient tous été publiés le 16 juillet. Les trois captures correspondent aux SHA-256 actuels de l’API et GnuPG renvoie GOODSIG et VALIDSIG pour l’empreinte 8F9ABC7EF3BA565F9DF1578C72160FD57B242967.
  • Cette vérification défend les octets capturés, sans authentifier seule l’autorité de la clé : le même environnement affiche TRUST_UNDEFINED, tandis que l’API décrit la release comme non immuable au moment de l’observation.
  • Un reçu opérationnel devrait conserver séparément le tag et le commit, l’actif et son hash, la signature et la décision de confiance, les paramètres du build, le binaire installé, l’activation et le retour arrière.

La chaîne de contrôle commence une commande trop tard

Le guide de huit pages se donne un objectif pratique : faire fonctionner FORT 1.7.0.experimental sur Ubuntu Server 26.04 en amd64/x86_64. Il explique qu’au cours du test, le paquet .deb demandait libmicrohttpd12 et libxml2, alors que cette version d’Ubuntu proposait des paquets autrement nommés. Le chemin retenu compile donc le source contre les bibliothèques de développement disponibles. Ce constat reste celui du guide ; les éléments examinés ici ne reproduisent pas indépendamment le défaut du paquet.

À partir de là, le document devient méticuleux. Il télécharge l’archive, l’extrait, lance ./configure, compile avec make -j"$(nproc)", puis installe sous privilèges élevés avec sudo make install. Il demande ensuite fort --version, inspecte ldd, réalise une première validation, vérifie les sorties, prépare le service et RTR, puis attire l’attention sur la synchronisation de l’horloge.

Ces contrôles ressemblent aux vérifications d’un voyageur arrivé à destination : identité déclarée, bagages présents, service joignable. Il manque le billet d’entrée, c’est-à-dire le lien entre le fichier reçu et l’objet que le projet disait avoir publié.

Le PDF ne contient ni SHA-256, ni checksum, ni .asc, ni keyring, ni commande de vérification de signature. Sa seule occurrence sémantique de firma porte sur les objets RPKI signés. La documentation d’installation conservée au commit de la release télécharge et installe elle aussi paquets ou archives sans vérifier un hash ou une signature détachée.

Les preuves existaient avant la publication du guide

GitHub situe la création de 1.7.0.experimental au 16 juillet 2026 à 01:52:42Z et sa publication à 03:45:33Z. Le tag annoté vise le commit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e; l’API du tag qualifie sa signature de valide et vérifiée.

L’archive a été jointe à 03:47:16Z, sa signature détachée à 03:47:19Z, et fort.keyring à 03:51:35Z. Le matériel nécessaire se trouvait donc sur la release plusieurs semaines avant le billet de LACNIC.

Lors de la capture du 31 août, les SHA-256 exposés par l’API étaient les suivants :

Élément SHA-256 observé
fort-1.7.0.experimental.tar.gz 70075f82effe5cf9752b13463f50c4379fdf93e5c28bdf6cba04e9621e2288cc
Signature .asc e648b9ff2075c6d78f4bf1a69c96a5b421757432b71f916a3118fb11ffe815ad
fort.keyring 8e4dfee468ad756bc89ffff3894692e87e66ffbd135dc697f3ffbac02116e6a6

Les octets récupérés séparément correspondent aux trois valeurs. Importer le keyring fourni et vérifier le tarball avec le .asc produit GOODSIG et VALIDSIG. L’empreinte complète est 8F9ABC7EF3BA565F9DF1578C72160FD57B242967; l’horodatage de la signature est le 16 juillet à 01:55:02Z.

Il faut commencer l’interprétation par ce résultat favorable. Rien dans les sources vérifiées ne montre que l’archive soit malveillante, substituée ou incorrecte. Rien n’attribue à cette installation une panne de validation ou un incident de routage. La capture correspond au digest actuel et sa signature détachée est mathématiquement valable avec la clé publique fournie.

Le statut TRUST_UNDEFINED renvoyé dans le même test ne retire pas cette validité. Il signale que la clé n’était pas certifiée par une signature déjà fiable dans l’environnement temporaire. La relation fichier–signature–clé est établie ; l’identité du détenteur et l’autorité organisationnelle de cette clé ne le sont pas par cette opération seule.

Le même mot « FORT » masque quatre objets

Le tag signé est un objet Git. Il atteste, selon le service, que le tag conduit au commit c67d14b…. Il ne s’étend pas automatiquement à l’archive chargée dans l’espace Releases.

L’actif de release est un deuxième objet. L’API lui associe un nom, une date et un digest courant. Elle indiquait aussi immutable: false, draft: false et prerelease: false le 31 août. La non-immuabilité ne prouve pas une modification. Elle oblige à dater le constat et interdit de conclure que chaque téléchargement passé avait nécessairement les mêmes octets.

La clé de signature est un troisième objet. Une bonne signature prouve la possession de la clé privée correspondante. Pour décider de lui faire confiance, l’opérateur doit obtenir l’empreinte par un canal authentifié qui ne se réduit pas au même emplacement de téléchargement, et connaître les règles d’autorisation, de rotation et de révocation.

Le binaire local est un quatrième objet. Entre l’archive et lui interviennent le système, le compilateur, les options de configuration, les en-têtes et les bibliothèques. fort --version et ldd sont des observations utiles, pas une preuve de build reproductible ni un hash du fichier installé. Les documents consultés n’avancent aucune revendication de reproductibilité bit à bit.

Une chaîne de contrôle ne consiste pas à déclarer ces quatre objets mauvais. Elle consiste à empêcher qu’un contrôle réussi sur l’un soit utilisé comme preuve silencieuse des trois autres.

Un reçu minimal préserverait chaque passage

Avant l’extraction, le guide pourrait fixer l’URL et le nom exacts de l’actif, publier le SHA-256 attendu, calculer le résultat observé, obtenir l’empreinte complète par une source indépendante, puis exécuter la vérification du .asc. Toute différence devrait interrompre la procédure et déclencher une demande de correction.

Après la compilation, six lignes de registre suffiraient :

Passage Trace durable
Projet → release Tag, commit cible, URL, heure de publication et état d’immuabilité observé
Release → actif Nom, URL, SHA-256 attendu et observé, heure de téléchargement
Actif → clé Hashes du .asc et du keyring, empreinte, source indépendante, décision et résultat
Source → build OS, architecture, compilateur, options et versions de dépendances
Build → système Chemin et digest du binaire, version, hashes des fichiers de service et de configuration
Système → exploitation Heure d’activation, version précédente, procédure de retour, rotation/révocation, corrections

Ce reçu ne transforme pas LACNIC en autorité unique. Les mainteneurs gouvernent les releases de FORT, GitHub fournit une surface de distribution, Ubuntu fournit des dépendances et chaque opérateur choisit sa racine de confiance et sa politique de routage. Le rôle éditorial de LACNIC est de ne pas effacer les frontières entre eux dans un chemin recommandé.

La commande sudo make install donne à cette précision une conséquence concrète. Elle ne démontre aucun danger en soi, mais franchit une frontière d’autorité locale. Un guide qui accompagne ce franchissement devrait conserver l’identité du résultat auquel cette autorité a été accordée.

Une lacune documentaire n’est pas une accusation d’exploitation

L’analyse porte sur ce que la publication enseigne. Elle ne dit pas qu’un lecteur a ignoré une signature. Une équipe peut avoir ajouté des contrôles internes, un miroir, une clé pré-approuvée, un système de build ou une validation de binaire que le guide ne voit pas.

Elle ne dit pas non plus qu’un actif a changé parce que la release était non immuable, ni que le digest actuel représente chaque téléchargement historique. Une signature valide avec le keyring fourni ne suffit pas à établir l’identité légale du signataire. Aucun élément ne montre une compromission, une substitution ou un événement de routage.

Enfin, le sujet diffère du transport d’informations ASPA vers un routeur et des valeurs RTR négociées. Cette autre surface se situe à la sortie du validateur. Ici, la question précède son démarrage : quelle preuve relie le programme qui produit la sortie à un actif et à une autorité acceptés ?

La correction raisonnable est donc proportionnée. Le guide teste déjà une grande partie du parcours et la release fournit déjà les pièces cryptographiques. Les relier ne garantit pas tout le logiciel, mais donne aux opérateurs une chronologie, un arrêt sur erreur et une possibilité de retour vérifiable.

Sources