Dis Next, c’est quoi un paquet reproductible ?
Determinism is sexy
Dans le domaine du libre, particulièrement des distributions Linux, la notion de « paquets reproductibles » est souvent présente. De quoi parle-t-on ? À quoi ça sert ? Quels sont les avantages, les limites ? On vous explique, en toute simplicité.
Vous venez d’installer un système Linux. Vous savez que tout le code (pour simplifier) est libre et open source. Soudain, une question vous assaille : comment être sûr que ce que vous venez d’installer correspond bien à ce code ?
Il s’agit autant d’une question de confiance envers l’éditeur ou la communauté concerné que de sécurité. On trouve depuis longtemps par exemple des empreintes cryptographiques (SHA-256 par exemple), qui permettent de comparer un téléchargement à la version présente sur le site. En comparant les deux empreintes, on peut s’assurer de la correspondance. Le site vous dit « L’empreinte de ce fichier est XYZ », vous permettant de vérifier que ce que vous avez récupéré est bien la même chose.
Toutefois, cette méthode ne dit rien de la manière dont ce fichier a été produit. Quand on télécharge une application par exemple, on ne sait rien de ce qui s’est passé avant sa mise à disposition. Et si le serveur de compilation avait été compromis ? Si des pirates se sont emparés d’une partie de l’infrastructure, les fichiers produits peuvent être compromis. La comparaison de l’empreinte ne sera alors d’aucun secours.
C’est quoi la reproductibilité ?
Pour avancer dans la vérification, on veut aller plus loin. Dans le monde du libre, on part du principe que n’importe qui peut regarder le code. En revanche, dans l’immense majorité des cas, les utilisateurs récupèrent des binaires, c’est-à-dire des versions compilées, prêtes à l’emploi. Un exemple classique est le noyau Linux : tout le monde peut voir ses sources, mais dans l’utilisation quotidienne, on se contente de récupérer les nouvelles versions via les mises à jour du système sous forme binaire, livrées sous forme de paquets.
Commentaires (4)
Modifié le 24 septembre à 15h19
« Papa, c'est quoi un paquet reproductible ?
-- C'est quand, avec les mêmes sources, on obtient toujours le même résultat.
-- Comme moi et ma sœur ?
-- Ben non, pour nous, ça marche pas comme ça. »
J'avais une autre variante en tête avec l'idée du paquet, mais je n'avais pas envie de me faire sabrer.
(edit pour la mise en forme de la liste)
Le 24 septembre à 16h39
Le 25 septembre à 11h15
La page Go utilise l'idiome :Une philosophie de vie, qui peut s'appliquer en tous temps, en tous lieux, pour toute chose… même si je constate encore & encore que certains opposent encore infantilement contrôle & manque de confiance, laquelle devrait donc, si on déroule le fil de cette logique, être aveugle.
Une création de paquet déterministe, donc indépendante de l'endroit utilisé : une forme d'empathie.
Permettre à d'autres de bénéficier du partage, sans se voir imposer de conditions d'utilisation.
Cela correspond aux objectifs recherchés de la philosophie du libre : partage, émancipation (voire libération), grandissement, etc.
Là encore, une philosophie de vie, qui peut s'appliquer en tous temps, en tous lieux, pour toute chose.
En somme, cela correspond bien à ce que le libre, les standards ouverts, l'interopérabilité, proposent & continuent de proposer dans ce qui forme systèmes & réseaux, au plus profond de ce que l'on utilise massivement quotidiennement sans plus même y penser.
Petit clin d’œil à ceux qui tentent d'exiger une absence d'idéologie ou de politique dans la technologie (pour mieux, in fine, imposer la/les leur-s, toute-s autre-s).
Modifié le 30 septembre à 07h33
La faille s'activait à la compilation depuis github en injectant discrètement la porte dérobée, cette porte était contenue dans les données de tests utilisés par l'automatisation de la chaîne de test compilation. (dans une ressource binaire pas directement visible quand on regarde le code source sur github.com, ni même synchronisé localement avec git clone.
Si ma mémoire ne me joue pas des tours; avec des sources reproductibles il aurait été très simple d'identifier un écart entre le binaire de la partie release proposer en ligne sur github (et infecté), et le binaire compilé localement depuis les sources du tag correspondant à cette release (qui n'aurait donc pas inclus la charge active).
*Edit: ma mémoire semble bonne :
Une version modifiée de build-to-host.m4 a été incluse dans le fichier tar de la version téléchargée sur GitHub, qui extrait un script qui effectue l'injection réelle dans liblzma. Ce fichier m4 modifié n'est pas présent dans le dépôt git ; il n'est disponible qu'à partir des fichiers tar publiés par le mainteneur, séparément de git[6]. Le script semble effectuer l'injection uniquement lorsque le système est compilé sur un système Linux x86-64 qui utilise glibc et GCC et est construit via dpkg ou rpm[6].*
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?