La page se tourne.
Le prochain chapitre arrive…
Psst… appropriez-vous votre lecture.
Polices et thèmes se trouvent dans Apparence. Vos yeux ont aussi leur mot à dire.
Le prochain chapitre arrive…
Independent parties can rebuild the same binary from source, raising trust in wallet releases.
Vérification de la lecture vocale du navigateur…
Cette lecture est actuellement disponible en anglais. L’interface utilise la langue choisie.
Lire l’original anglais →Reproducible builds, also known as deterministic compilation, is a process of building software which ensures the resulting binary code can be reproduced. Source code compiled deterministically will always output the same binary.
Reproducible builds can act as part of a chain of trust; the source code can be signed, and deterministic compilation can prove that the binary was compiled from trusted source code. Verified reproducible builds provide a strong countermeasure against attacks where binaries do not match their source code, e.g., because an attacker has inserted malicious code into a binary.
This is a relevant attack; attackers sometimes attack binaries but not the source code, e.g., because they can only change the distributed binary or to evade detection since it is the source code that developers normally review and modify. In a survey of 17 experts, reproducible builds had a very high utility rating from 58.8% participants, but also a high-cost rating from 70.6%. Various efforts are being made to modify software development tools to reduce these costs.
For the compilation process to be deterministic, the input to the compiler must be the same, regardless of the build environment used. This typically involves normalizing variables that may change, such as order of input files, timestamps, locales, and paths.
Additionally, the compilers must not introduce non-determinism themselves. This sometimes happens when using hash tables with a random hash seed value. It can also happen when using the address of variables because that varies from address space layout randomization (ASLR).
Build systems, such as Bazel, GNU Guix, and Gitian, can be used to automate deterministic build processes.
The GNU Project used reproducible builds in the early 1990s. Changelogs from 1992 indicate the ongoing effort.
One of the older projects to promote reproducible builds is the Bitcoin project with Gitian, and later, GNU Guix. In 2013, the Tor (anonymity network) project started using Gitian for their reproducible builds.
Starting in 2011, a reproducible Java build system was developed for the decentralized peer-to-peer FOSS project DirectDemocracyP2P. The concepts of the system's application to automated updates recommendation support was first presented in April 2013 at Decentralized Coordination. A treatise focusing on the implementation details of the reproducible Java compilation tool itself was published in 2015.
In some cases other changes must be made to make a build process reproducible. For example, some data structures do not guarantee a stable order in each execution. A typical solution is to modify the build process to specify a sorted output from those structures.
Sélectionné et remis en forme à partir de Reproducible builds, par ses contributeurs, sous CC BY-SA 4.0. Révision 1369484582. Les sections et la mise en forme ont été abrégées ; la révision liée fournit le contexte complet et l’historique des contributions. Ce texte de référence conserve sa licence. Les liens de citation supplémentaires proviennent de cette révision et n’ont pas été vérifiés indépendamment ici.