Reproducible Firmware Build désigne une compilation où les mêmes sources, environnement et instructions produisent des sorties prédéfinies identiques octet par octet. Il faut préciser la version, le modèle de l’appareil et le périmètre comparé, notamment si la publication contient une signature supplémentaire.
L’affirmation porte sur une sortie définie, par exemple une image de micrologiciel, et non automatiquement sur chaque fichier ou journal. Un comportement équivalent ne suffit pas : on recherche des octets identiques, généralement au moyen d’un hachage cryptographique. Des sources ouvertes sans compilation répétable ne démontrent pas seules ce lien avec le binaire publié. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Consignez le commit exact, les dépendances et leurs versions, le compilateur, les options de compilation, les variables d’environnement pertinentes et le modèle cible. Le nom du projet ou une branche évolutive ne suffit pas. Les informations nécessaires doivent être publiées ou enregistrées pendant la compilation ; sinon les différences ne peuvent être évaluées de manière fiable. [Reproducible Builds — Definition] [Reproducible Builds — Recording the environment]
Un compilateur peut inscrire le chemin du répertoire de travail dans les informations de débogage. Les mêmes sources placées à deux endroits peuvent alors produire des fichiers différents. Le chemin peut être fixé à l’avance ou normalisé par une procédure prise en charge. Cette règle doit appartenir à la recette ; supprimer ensuite des différences inconnues invaliderait la vérification. [Reproducible Builds — Build paths]
Une signature valide lie une publication à sa clé de signature dans un modèle de confiance donné. Une compilation indépendante examine le rapport entre sources et résultat binaire. Le fichier officiel signé peut contenir des données absentes de la compilation locale non signée. Comparer simplement les fichiers complets peut donc ne pas constituer le bon test de la reproductibilité annoncée. [Trezor — Reproducible build verification]
La documentation Trezor sélectionne une version et un modèle, construit l’image dans l’environnement indiqué et la compare à la publication officielle. Avant la comparaison, elle décrit la mise à zéro de champs de signature précis ; les anciens formats présentent aussi des différences d’en-tête. La structure dépend du modèle et de la version. Une procédure ne doit donc pas être appliquée aveuglément à une autre image ; la signature d’origine se vérifie séparément. [Trezor — Reproducible build verification]
Vérifiez d’abord la révision, le modèle, la variante du micrologiciel, les dépendances et les transformations déclarées de l’image. Conservez les fichiers originaux et la trace de l’écart. Celui-ci peut provenir d’une erreur de recette ou d’environnement, mais aussi d’un binaire distribué modifié ; il n’en établit pas seul la cause. Ne déclarez pas la sortie vérifiée avant d’avoir expliqué l’écart et répété le contrôle. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
Des sources défectueuses ou malveillantes peuvent être parfaitement reproductibles. Un compilateur commun non fiable peut introduire la même modification dans tous les résultats ; répéter le même outil n’est pas un audit indépendant du compilateur. Les composants binaires fermés limitent ce qui peut être reconstruit depuis les sources disponibles. Des fichiers identiques ne vérifient ni l’authenticité du matériel ni ce qui est effectivement installé sur un appareil précis. [Wheeler — Countering Trusting Trust] [Reproducible Builds — Definition]
Un compte rendu utile indique qui a compilé, depuis quel commit, selon quelle recette, pour quel modèle et quels fichiers ont été comparés. Ajoutez l’algorithme de hachage, les résultats et les exceptions exactes concernant les signatures. D’autres personnes compilant indépendamment réduisent la dépendance envers un seul éditeur, mais ne remplacent pas l’examen des sources, du processus de mise à jour et de la sécurité globale de l’appareil. [Reproducible Builds — Recording the environment] [Reproducible Builds — Build infrastructure threats]
Même code, zone de signature différente
Deux personnes utilisent les mêmes commit, modèle et environnement. Leurs images locales ont le même SHA-256, tandis que l’image officielle signée en a un autre. Si la documentation définit précisément les champs de signature, elles comparent des copies après la transformation prescrite. La correspondance concerne alors ce contenu défini ; la signature d’origine est vérifiée séparément. Aucun autre écart ne doit être simplement supprimé.
Pour une vision complète, lisez aussi Hardware Wallet, Clé privée, Cold Storage, Secure Element. Cette entrée est également citée par COLDCARD RNG Incident (2026).
01Un hachage identique suffit-il à conclure que le micrologiciel est sûr ?+
Non. La correspondance établit le résultat d’une comparaison précise, pas l’absence de défauts. Des sources malveillantes ou un compilateur commun non fiable peuvent produire des sorties identiques. Il faut distinguer vérification de compilation, examen des sources et confiance dans l’appareil.
02Un hachage différent pour une publication signée signifie-t-il forcément une attaque ?+
Non. Une image signée peut contenir des champs de signature ou des en-têtes différents, décrits à l’avance. Vérifiez d’abord la bonne version, le modèle et la méthode de comparaison. Un écart inexpliqué ne peut toutefois être déclaré conforme ni contourné en supprimant arbitrairement des octets.