Differences between revisions 125 and 126
Revision 125 as of 2014-01-19 14:16:16
Size: 23480
Editor: Lunar
Comment: add link to the sources of the FOSDEM14 slides
Revision 126 as of 2014-01-20 15:34:26
Size: 23510
Editor: Lunar
Comment: mention what was varying between build and rebuild
Deletions are marked like this. Additions are marked like this.
Line 67: Line 67:
 * [[ReproducibleBuilds/Rebuild20130907|2013-09-07]] by David Suárez.  * [[ReproducibleBuilds/Rebuild20130907|2013-09-07]] by David Suárez. Variations: time, build path.

It should be possible to reproduce, byte for byte, every build of every package in Debian.

For now, we will start with a few maintainers who want to opt in to this goal as we flesh out the details of what will make it possible. This page tracks our progress.

To participate in the project, we recommend you create an account on this wiki, and then "watch" this page and join the reproducible-builds@lists.alioth.debian.org mailing list.

Alioth project

Drivers

Why do we want reproducible builds?

  • Independent verifications that a binary matches what the source intended to produce.
  • Help Multi-Arch: same packages co-installation (as they need every matching file to be byte identical).

  • Be able to generate debug symbols for packages which do not have a “debug package”.

Others?

Status

  • Proof of concept success: hello package: Contents of data.tar.gz and control.tar.gz are the same even if you build the package twice (as of version 2.8-4, per 719848).

  • Buy-in within Debian: 5 packages from 5 maintainers are interested, of which 0 so far have reproducible contents of {data,control}.tar.gz

  • Waiting on a few dpkg bugs for avoiding timestamps and file order inconsistency in {data,control}.tar.gz (or .xz)
  • Lunar has a dpkg branch that handles timestamps, file order in .deb and .changes, and pass the right CFLAGS to get deterministic debug symbols. See below.
  • A first rebuild of the archive was done by David Suárez with the pu/reproducible_builds branch of dpkg. This has already uncovered several archive-wide issues that we can address.

  • It is possible to reinstall exactly the same set of Debian packages used for the initial build using snapshot.debian.org.

Useful things you (yes, you!) can do

  • Sort out the results of the rebuild done by David Suárez with the pu/reproducible_builds branch of dpkg.

  • Find a way to remove prevent jar from writing timestamps. A thread from 2008 on a Fedora mailing list seems to be on point; they suggest a patch to the zipnote command which allows timestamps to be updated in zip files without unpacking. AFAICT, this now five-year-old patch hasn't made it into upstream Infozip, let alone Debian.

  • Fing a way to prevent javadoc from writing timestamps.
  • Find a way to prevent Epydoc from writing timestamps and output links in filesystem order.
  • Understand why binaries produced by Mono are different.
  • Prepare the next archive rebuild:
    • build the latest pu/reproducible_builds branch for dpkg; DONE 2014-01-17 Lunar

    • recompile binutils with --enable-deterministic-archives. DONE 2014-01-17 Lunar

  • Write a script to rebuild a package from a list of binary packages and their respective versions. See below for some preliminary work by Lunar that has already been done. One way to do that is to download the deb files from snapshot.debian.org and then put them into a chroot with pbuilder, and then use pbuilder to do a build of the desired Debian package.
  • Research about other distributions: NixOS, SUSE (see build-compare), then write about it on your blog and link to it on this wiki page.

  • Write a tool to take a *.deb file and extract, into a YAML file, all the non-essential metadata about a *.deb -- for now, that is the order of files within the control.tar and data.tar, and the mtime of them. You can use the iotop package as a starting point for this. Once we can generate this file, we can write a second tool to re-apply the metadata to a target *.deb file. That way you will be able combine a new, rebuilt *.deb with the YAML file, and create a binary-identical *.deb to the one in the Debian archive.

If you want to help with this, join #debian-devel and ping paulproteus (Asheesh) or tumbleweed (Stefano) or the other people listed on this page.

Archive wide rebuilds

  • 2013-09-07 by David Suárez. Variations: time, build path.

Use cases

  • If the Debian build daemons are compromised, end users can assure themselves that their binaries are OK if they can regenerate them (and their build dependencies). (You could use a more complicated equivalence test than "do the hashes match?" but if the hashes do match, this is simple.)

Detailed package status list

  • alpine (Asheesh Laroia)
    • Status: Untested
  • haveged (Lunar)
    • Status: content of data.tar and control.tar do not vary with time. control.tar is different because of tar member's mtimes. Same for data.tar.

  • iotop (pabs)
    • Status: data.tar and control.tar different (contents same): because the tar mtime/check_sum members differ (used hachoir-urwid to check)
  • debhelper (joeyh)
    • Status: contains timestamps; got initial reproducible build using faketime with clock stuck at epoch. Build environment recording needed in order to get long-term reproducible build.
  • magit (lindi)
    • Status: Unknown
  • kfreebsd-9 (debian-bsd@lists.d.o)

    • Status:
      • already, kernel images of kfreebsd-9.2-1-486 and kfreebsd-9.2-1-686 were identical when separately built by kfreebsd and linux buildds, except for a single byte in the ELF header which we'll get fixed
      • we still see full build paths in some loadable kernel modules whether using GCC or Clang (is it DWARF data?) but are interested in fixing this
      • varying readdir order is a problem for {data,control}.tar if built on ZFS
    • stevenc's own opinions:
      • I think it is a brilliant example of the concept, to have systems with different kernels/arch generate the same result, showing integrity; and it may reveal some toolchain/packaging bugs too
      • I'm aiming for determinism in more of the kfreebsd base packages
      • for binaries, I'm mostly interested in the file hash (and md5sums file in the .deb) being identical. I'm less concerned yet about timestamps and the signature of the .deb as a whole. It would be really neat if that can be worked out though. That would allow deduplication - by ZFS, or through other means - on Debian mirror sites, or maybe snapshots.d.o, of .deb files whose contents didn't really change between versions.
      • the work of this project should generally improve compressability of the archive, because it is reducing the amount of 'entropy' incidentally being added to the output of package builds; and probably allowing .deb deltas to be smaller.

Reproducing builds

There are two sides to the problem: first we need to record the initial build environment, and then we need a way to set up the same environment.

Recording the environment

The right place to record the build environment is the .changes file. Rationale: it lists the checksums of the build products and is signed by either the maintainer or the buildd operator.

To add a field to the .changes file, we need to call dpkg-buildpackage using something like:

dpkg-buildpackage --changes-option="-DBuild-Environment=$(
COLUMNS=999 | dpkg -l | awk '
            /^ii/ { ORS=", "; print $2 " (= " $3 ")" }' |
        sed -e 's/, $//'
)"

The idea is not new, see 138409. The above could eventually be integrated in dpkg proper if our experiments turn successful.

The dh-buildinfo script already captures the build environment quite nicely. It currently encode the information about the build environment in a buildinfo_$ARCH.gz in the doc directory. For our goal, we believe that such information should not be recorded in the binary package itself.

Lunar wrote on 2013-09-08 to Yann Dirson to ask his opinion. Yann agrees that what buildinfo produces should not be in the .deb file but rather a separate file. He's advocating for having an additional file as part as an upload rather than adding fields in .changes. He also agree that what dh-buildinfo produces should actually be done at the dpkg level.

In any cases, we should simply re-use or adapt dh-buildinfo, and turn it into dpkg-buildinfo. Either it should produce an extra file that is bundled together with a .changes or add some extra fields directly in .changes.

(See 719854 for the first attempt which tried using XC- field in debian/control.)

Reproduce the build environment

Actions:

  • We need a script that would take a list of binary packages and their respective version, installs them in a chroot and starts the build. Maybe based on pbuilder?

Ruby script that generates URL to .deb on snapshot.debian.org from a list of binary packages and their respective version: http://people.debian.org/~paulproteus/lunar-verify-script.rb

Here's another potential piece of the puzzle. The following script will convert a RFC822 date (as found in a .changes) to the URL of the last known archive state recorded by snapshot.debian.org. This might be useful to debootstrap the proper chroot before installing packages…

require 'date'
require 'uri'
require 'net/http'
require 'nokogiri'

changes_date = 'Mon, 30 Jan 2012 12:52:28 +0100'

build_date = DateTime.rfc822(changes_date)
url = "http://snapshot.debian.org/archive/debian/?year=#{build_date.year}&month=#{build_date.month}"
response = Net::HTTP.get_response(URI.parse(url))

run = nil
doc = Nokogiri::HTML(response.body)
doc.css('p a').each do |link|
  date = DateTime.parse(link.content)
  break if date >= build_date
  run = link['href']
end
puts "http://snapshot.debian.org/archive/debian/#{run}"

Note : it would probably be a lot better of adding a new query to the machine interface of snapshot.d.o instead of parsing HTML.

Reported bugs

Overview of all bug reports concerning reproducible builds

All bugs relevant to the reproducible builds project should use usertags with user reproducible-builds@lists.alioth.debian.org.

Current usertags in use:

toolchain
affects a tool used by other package build systems
infrastructure
affects the whole Debian infrastructure or policies
timestamps
time of build in recorded during the build process
fileordering
build output varies with readdir() order
buildpath
path of sources is recorded during the build process

Different problems, and their solutions

Build systems tend to capture information about the environment that makes them produce different results accross different systems, despite having the same architecture and software installed.

Ideally, such variations should be fixed in the build system itself, but it might sometimes not be possible.

Non-problems

  • You might think ELF binaries (e.g. /usr/bin/hello in the hello package) have embedded timestamps. Luckily, they don't!

Files in data.tar.gz contains build paths

These should really be patched out in one way or another. This is not useful information and can actually hide real bugs.

DWARF data

The build path is embedded in DWARF sections of ELF files. Like Fedora, we should replace actual build paths to a canonical location in /usr/src.

One option is to do so by adding two CFLAGS for GCC:

  1. -fdebug-prefix-map to replace the build path by a predetermined path.

  2. -gno-record-gcc-switches to prevent the previous option to be recorded in the debug file (as it changes with the build path).

Both are documented in GCC's manual.

We can pass both options using the dpkg-buildflags mechanism. Lunar's branch has a patch for that.

Problems with that approach:

  • ('minor') Some build systems do not build the objects in the same directory as the source. In that case, we get a stable name in DW_AT_comp_dir, but it does not match the source of an unpacked package in /usr/src.

  • ('major') Some build systems record the value of CFLAGS and reuse it to build extensions. This is what Ruby MRI does. This means that extensions will not get a stable Build Id without further work.

Another option is to use debugedit. Currently, it needs to be used together with -fno-merge-debug-strings because the hashtable used when strings are merged will output strings in a different order depending on the initial build path.

Files in data.tar.gz depends on readdir order

The build system needs to be patched to sort directory listings.

Epydoc

It looks like python-epydoc will produce links in an order that depends on the readdir order. This needs to be investigated.

Files in data.tar.gz varies with the locale

Builds should be made with LC_ALL=C.UTF-8.

It's quite unpractical to force such value in debian/rules and there is actually no reason this should not be the default.

Actions:

  • We could make dpkg-buildpackage exports this variable; but we would need to change the policy to make dpkg-buildpackage be the canonical solution to build package.

Files in data.tar.gz contains hostname, uname output, username

Actions:

  • We could write a LD_PRELOAD library that could answers consistent results for several system calls on the same model as libfaketime. Bdale suggested we call it liblietome.

Files in data.tar.gz contains timestamps

  • Recommended solution:
    • Use the timestamp of the of the last debian/changelog entry as reference.
    • touch all files to the reference timestamp before building the binary packages.
    • gzip -n when gzipping anything
    • get rid of non-determinisim (yup...)
    • Alternate solutions:
      • (or) libfaketime (probably breaks some things) (sudo apt-get install faketime)

For the worse cases, we could record the calls to gettimeofday() on the first build and have something like libfaketime replay them on rebuilds.

.a files

.a files are ar archive. GNU ar has a deterministic mode which will use zero for UIDs, GIDs, timestamps, and use consistent file modes for all files.

binutils can be built with --enable-deterministic-archives to make it the default.

Epydoc

python-epydoc will add timestamps to the HTML file it produces. This needs to be fixed.

javadoc

javadoc will add timestamps to the HTML file it produces. This needs to be fixed.

PHP PEAR registry files

PHP PEAR registry files contain timestamps in _lastmodified member.

Members of control.tar have varying mtime

We can fix this by giving tar the --mtime= option with the date of the last debian/changelog entry or a similar fixed point in time. Change to be done in dpkg-deb/build.c:do_build() around line 462.

Lunar's branch use a single timestamp for all mtimes of tar members and allow to preset it during rebuilds, see below.

{data,control}.tar.{gz,xz,bz2} does not have timestamps

  • dpkg 1.17.1 does not store a timestamp for the .gz versions of these files.
  • *.xz and *.bz2 seem to provide no ability to store a timestamp.

{data,control}.tar.{gz,xz,bz2} will store files in readdir order

This is dependent on an accident of filesystem layout at build time, so it would sometimes not be reproducible.

We should probably fix this in dpkg by sorting the contents of the tar files.

Changes are discussed in 719845. Test case patch for pkg-tests. Patches that fork `sort` to get a stable order for files in control and data archives.

.deb ar-archive header contains a timestamp

.deb are ar-archives. The header currently contains the “current time”. It is written by dpkg at line line 103 of lib/dpkg/ar.c.

Guillem said he would rather keep this.

Lunar's branch use a single timestamp for all ar headers and allow to preset it during rebuilds, see below.

dh-buildinfo

dh-buildinfo used to encode a timestamp in the gzip file it produces, and also did not output the package list in the same order on every run. A patch had been submitted in 722186 and the packages should be good with version 0.10.

building the kernel

See dedicated page: SameKernel.

Custom build environment

We maintain a set of modifications to the toolchain to perform our experiments.

debhelper

The pu/reproducible_builds debhelper branch in the reproducible repository makes dh_strip call debugedit to adjust the source path embedded in debug objects.

dpkg

The pu/reproducible_builds dpkg branch in the reproducible repository makes:

  1. file order deterministic in control and data part of the .deb,
  2. uses a single timestamp for .deb mtimes and allows to preset the timestamp,
  3. adjust dpkg-buildflags to pass -fno-merge-debug-strings in CFLAGS and CXXFLAGS

binutils

binutils has been rebuilt with the --enable-deterministic-archives flag passed to ./configure.

Usage example

$ apt-get source hello
$ cd hello-2.8
$ dpkg-buildpackage
[…]
$ cp ../hello_2.8-4_amd64.deb ../hello_2.8-4_amd64.deb.orig
$ DEB_BUILD_TIMESTAMP=$(date +%s -d"$(sed -n -e 's/^Date: //p' ../hello_2.8-4_amd64.changes)") dpkg-buildpackage
[…]
$ sha256sum ../hello_2.8-4_amd64.deb ../hello_2.8-4_amd64.deb.orig
1e944abfceac7e593f6706da971e0444e5cee9aab680de5292d52661940ee9c4  ../hello_2.8-4_amd64.deb
1e944abfceac7e593f6706da971e0444e5cee9aab680de5292d52661940ee9c4  ../hello_2.8-4_amd64.deb.orig

Success!

bash script to compare two package builds

Usage: ./diffp r1/hello_2.8-4_amd64.changes r2/hello_2.8-4_amd64

The script is available in the misc.git repository.

How to build a deb using faketime

sudo apt-get install faketime
echo > /tmp/fakeroot-faketime << EOF
faketime "2013-08-15T11:02:00" fakeroot "$@"
EOF
chmod a+x /tmp/fakeroot-faketime
dpkg-buildpackage -r/tmp/fakeroot-faketime

Note that this retians *one* timestamp, which is the timestamp of the 'ar' container of the *.deb. To erase that, somehow regenerate the package within the fakeroot-faketime environment by using dpkg-deb to unpack it, then dpkg-deb to repack it.

Note also that this is a total hack and not something I (AsheeshLaroia) think it makes sense to do on the Debian build daemons. In particular, some programs (e.g., gpg) hang forever when time does not advance.

Upstream changes may solve the problems we face with faketime 0.9.1. (rbalint) Faketime upstream has been improved to advance time linearly at a preset pace per each time() call and save/load timstamps. We could try rebuilding many packages saving timestamps in the first build and replaying them in successive builds. For example gnupg 1.4.14-1 builds fine:

NO_FAKE_STAT=1  ~/projects/libfaketime.git/src/faketime -f '+0 i0.01' dpkg-buildpackage -rfakeroot -us -uc

References

Presentations

Publicity

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