Got a spare moment? Please migrate this to our new webpages

With free software, anyone can inspect the source code for malicious flaws. But Debian provide binary packages to its users. The idea of “deterministic” or “reproducible” builds is to empower anyone to verify that no flaws have been introduced during the build process by reproducing byte-for-byte identical binary packages from a given source.

More information about reproducible builds in general are available at

Why do we want reproducible builds?

Reproducing builds

There are two sides to the problem: the build environment needs to be recorded during the initial build, and the same environment needs to be reproduced for later rebuilds.

Recording the environment

Information on a build will be recorded in a new control file with extension `.buildinfo`.

Reproduce the build environment

This is work-in-progress.

See Fun with buildinfo (2017).

See also srebuild (2015). The srebuild program is a sbuild wrapper which finds a timestamp from containing all versions of the binary packages in a .buildinfo file and then carries out the build with the right versions installed.



This section lists URLs, people, and dates for when other people have publicly expressed interest, or shared information about, the project.

Weekly reports

Stretch cycle

GSoC 2015: akira

GSoC 2015: Dhole

Related projects

Further work

Having reproducible builds allows us to trust binary packages better, because it becomes easier to have:

Kernel packages

Special features of kernel packages (including bootloaders and hypervisors) - GRUB2, Xen, linux, kfreebsd...

Then we would be better protected from something that could affect many systems at once, such as a kernel vulnerability; or widespread infection by a rootkit, which now must be compatible with more than one type of kernel to go unnoticed.