Builds reproductibles : pourquoi vous ne devriez pas avoir à nous faire confiance

Toute conversation sur la sécurité finit par arriver à la même question : à qui faites-vous confiance ? Pour le logiciel, la réponse historique est : à ceux qui ont construit les binaires. C’est beaucoup de confiance accordée à des machines que vous ne verrez jamais.

Un binaire, qu’il s’agisse d’un noyau, d’une application de bureau ou d’un paquet dans un dépôt, est une boîte noire à moins d’avoir été produit d’une manière que n’importe qui peut reconstituer. La compromission peut venir du dépôt source, des machines de build ou de la chaîne d’outils elle-même. Les options habituelles sont de croire le fournisseur sur parole ou de passer des semaines à démonter l’artefact pièce par pièce.

Les builds reproductibles offrent une troisième voie.

Ce que la reproductibilité vous donne

Un build est reproductible lorsque le fait d’alimenter les mêmes sources dans la même chaîne d’outils et le même environnement produit un résultat identique octet pour octet, sur des machines différentes, par des personnes différentes, et au fil du temps.

Quand cela tient, quelque chose d’utile émerge : n’importe qui peut vérifier nos versions de manière indépendante, sans nous.

• Des chercheurs indépendants peuvent recompiler nos sources publiées et comparer les sommes de contrôle avec les artefacts officiels.
• Des auditeurs peuvent confirmer qu’une version correspond au code qu’ils ont examiné, sans dépendances cachées ni modifications de dernière minute.
• Même un serveur de build compromis cesse d’être une menace silencieuse. Un artefact falsifié est détecté dès que quelqu’un reconstruit à partir des sources et compare les sommes de contrôle.

Ce que cela demande en pratique

La reproductibilité est plus une discipline qu’une technologie. Concrètement cela signifie :

• Normaliser tout ce qui est fluctuant. Horodatages, chemins embarqués, locales et ordre des fichiers doivent être épinglés ou supprimés.
• Des environnements déterministes. Chaque build se déroule dans un conteneur isolé et épinglé, pour que « mêmes sources » inclue vraiment « même environnement ».
• Des outils stables. Options de compilation, versions d’outils et durcissement font partie de la recette, pas des notes de bas de page.
• Un produit durci. Un build reproductible d’un binaire fragile reste fragile, aussi la chaîne d’outils applique l’ensemble des mitigations d’exploitation (protection de pile, PIE, fortify-source et compagnie) par défaut.

Par où cela s’arrête

La reproductibilité ne prouve pas que les sources elles-mêmes sont saines. Un build reproductible d’un code malveillant reste un code malveillant. C’est pourquoi l’autre moitié de l’exercice doit être la revue de source et la vérification des contributeurs.

Ce que la reproductibilité fait, c’est éliminer toute une classe de prétentions invérifiables. Quand une organisation vous affirme « voici le build exact de notre système d’exploitation », vous pouvez vérifier.

Ce que cela signifie pour Citadel

Pour un système d’exploitation conçu pour résister à des adversaires sophistiqués, la reproductibilité n’est pas un atout. La base de Citadel est construite ainsi dès le premier octet : chaque mise à jour est atomique, signée et reproductible à partir de sources publiques. Si vous ne voulez pas nous faire confiance, vous n’avez pas à le faire. Construisez vous-même, ou attendez les chercheurs indépendants qui le feront.

Les prochains articles détailleront le pipeline de build réel : les conteneurs, les pins, et comment une somme de contrôle arrive sur la page téléchargement.