Differences between revisions 1 and 382 (spanning 381 versions)
Revision 1 as of 2013-08-15 23:40:25
Size: 3244
Comment: initial page
Revision 382 as of 2019-09-27 23:34:40
Size: 7814
Editor: HolgerLevsen
Comment: shuffle a bit around
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
== The goal == {{{#!wiki important
Got a spare moment? Please migrate this [[https://reproducible-builds.org/|to our new webpages]]…}}}
Line 3: Line 4:
It should be possible to reproduce, byte for byte, every build of every package in Debian. [[https://reproducible-builds.org|{{attachment:r-b-logo.png}}]]
Line 5: Line 6:
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.
It should be possible to reproduce, byte for byte, every build of every package in Debian. More information about reproducible builds in general are available at [[https://reproducible-builds.org|reproducible-builds.org]].
Line 9: Line 8:
== Status == ||||||||<tablestyle="width: 800px;font-size: 1.2em; vertical-align: top">||
||<style="width: 25%;vertical-align: top;text-align: center">[[ReproducibleBuilds/About|{{attachment:ReproducibleBuilds/rb-about.png|About}}]] <<BR>> [[ReproducibleBuilds/About|About]] ||<style="width: 25%;vertical-align: top;text-align: center">[[ReproducibleBuilds/Howto|{{attachment:ReproducibleBuilds/rb-howto.png|Howto}}]] <<BR>> [[ReproducibleBuilds/Howto|Make a package reproducible]] ||<style="width: 25%;vertical-align: top;text-align: center">[[https://reproducible-builds.org/contribute/|{{attachment:ReproducibleBuilds/rb-contribute.png|Contribute}}]] <<BR>> [[ReproducibleBuilds/Contribute|How to help]] ||<style="width: 25%;vertical-align: top;text-align: center">[[ReproducibleBuilds/ExperimentalToolchain|{{attachment:ReproducibleBuilds/rb-toolchain.png|Toolchain}}]] <<BR>> [[ReproducibleBuilds/ExperimentalToolchain|Experimental toolchain]] ||
||<style="width: 25%;vertical-align: top;text-align: center">[[ReproducibleBuilds/History|{{attachment:ReproducibleBuilds/rb-history.png|History}}]] <<BR>> [[ReproducibleBuilds/History|Project history]] ||<style="width: 25%;vertical-align: top;text-align: center">[[https://salsa.debian.org/reproducible-builds/|{{attachment:ReproducibleBuilds/rb-alioth.png|Salsa / Gitlab}}|class=]] <<BR>> [[https://salsa.debian.org/reproducible-builds/|Salsa project / Gitlab|class=]] ||<style="width: 25%;vertical-align: top;text-align: center">[[https://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=reproducible-builds@lists.alioth.debian.org|{{attachment:ReproducibleBuilds/rb-bugs.png|Bugs}}|class=]] <<BR>> [[https://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=reproducible-builds@lists.alioth.debian.org|Bug reports|class=]] ||<style="width: 25%;vertical-align: top;text-align: center">[[https://reproducible.debian.net/|{{attachment:ReproducibleBuilds/rb-jenkins.png|Jenkins}}|class=]] <<BR>> [[https://tests.debian-reproducible.org/|Continuous integration|class=]] ||
Line 11: Line 12:
 * hello package: Contents of data.tar.gz and control.tar.gz can be made reproducible when 'gzip' replaced by 'gzip -n' in debian/rules. (#xyz) = Status =
Line 13: Line 14:
 * Waiting on a few dpkg bugs for avoiding timestamps and file order inconsistency in {data,control}.tar.gz (or .xz) {{{#!wiki important
Reproducible builds of Debian as a whole is still not a reality, though individual reproducible builds of packages are possible and being done. So while we are making very good progress, it is a ''stretch'' to say that Debian is reproducible.
}}}
Line 15: Line 18:
 * 5 packages from 5 maintainers are interested, of which 0 so far have reproducible contents of {data,control}.tar.gz  * Most packages built in sid today are reproducible under a [[https://www.debian.org/doc/debian-policy/#reproducibility|fixed build-path and environment]].
 * We have a new control file `*.buildinfo` that records the build environment, see DebianMan:deb-buildinfo for reference. Older design drafts are [[ReproducibleBuilds/BuildinfoSpecification|here]].
 * We have a [[https://reproducible.debian.net/|continuous integration]] platform that builds and immediately rebuilds packages. With this we can detect problems related to timestamps, file ordering, CPU usage, (pseudo-)randomness and [[https://reproducible.debian.net/index_variations.html|other things]].
 * We are [[https://reproducible.debian.net/unstable/amd64/index_notes.html|examining packages]] and sorting out [[https://reproducible.debian.net/index_issues.html|common problems]].
 * Many patches have already been [[https://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=reproducible-builds@lists.alioth.debian.org|submitted]], and we are continuously writing new ones.
 * You can check which packages installed on your system are still unreproducible by using the `reproducible-check` script in the `devscripts` package.
Line 17: Line 25:
 * You can use a script to rebuild a package, with the same build-depends that were used by the build daemons. See "How to reproduce a build" below. = Big outstanding issues =
Line 19: Line 27:
 * Things that need further investigation (by e.g. you!)
   * Document how to use Lunar's script to reproduce a build.
   * Find out if {control,data}.tar.gz files created by dpkg 1.17.1+ have a timestamp embedded.
These are the critical items necessary to have reproducible builds for at least the required packages of Debian
Line 23: Line 29:
== Use cases ==  * [[DebianBug:900837|#900837: Mass-rebuild of packages for reproducible builds]] (blocked by #894441)
 * [[DebianBug:763822|#763822: ftp.debian.org: please include .buildinfo file in the archive]], with this two related bugs:
  * [[DebianBug:862073|#862073: ftp.debian.org: Please POST .buildinfo files to buildinfo.debian.net]]
  * [[DebianBug:862538|#862538: security.debian.org: Please POST .buildinfo files to buildinfo.debian.net]]
 * [[DebianBug:900918|#900918: debian-installer: Please make the generated images reproducible]], see also [[DebianBug:920631|#920631]] and [[DebianBug:920676|#920676]]
 * User-facing interfaces (see proof-of-concept in [[DebianBug:863622|#863622: apt: warn when installing packages that are not reproducible]]
 * [[DebianBug:774415|#774415]] devscripts: please add the srebuild wrapper for reproducible builds - package it standalone? https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup/blob/master/builder/srebuild has another variant
 * [[DebianBug:894441|#894441: binNMUs should be replaced by easy "no-change-except-debian/changelog-uploads"]] (as of 20190302, 12% of all binaries in Buster were binNMUs.)
Line 25: Line 38:
 * 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.)  * currently debian-policy (thanks to [[DebianBug:844431|#844431]]) says "packages ''should'' be reproducible", though we aim for "packages ''must'' be reproducible" though it's still a long road until we'll be there: currently (Oct 2018) there are more than 1250 unreproducible packages in Buster, thus if policy would be changed today, 1250 packages would need to be kicked out of Buster (well, or fixed) immediatly, so this policy change right now is not feasable.
Line 27: Line 40:
== Detailed package status list ==
Line 29: Line 41:
 * alpine (Asheesh Laroia)
   * Status: Untested
 * haveged (Lunar)
   * Status: Unknown
 * iotop (pabs)
   * Status: Unknown
 * debhelper (joeyh)
   * Status: Unknown
 * magit (lindi)
   * Status: Unknown
= Annoying but not major =
Line 40: Line 43:
== How to reproduce a build ==  * [[DebianBug:869184|#869184: dpkg: source uploads including _amd64.buildinfo cause problems]]
 * [[DebianBug:802241|#802241: dpkg: please store the hash of the installed .deb and allow to query it]]
Line 42: Line 46:
* Someone needs to document Lunar's script here: http://people.debian.org/~paulproteus/lunar-verify-script.rb = Nice to have =
Line 44: Line 48:
== Known bugs we are waiting on ==  * Tighten up the Policy definition of "reproducible" to be stricter about environment variables and build paths.
 * Discuss which environment variables we should blacklist or whitelist, [[DebianBug:876055]].
 * [[DebianBug:929397|#929397: ftp.d.o: please upload LTS .buildinfo files to ftp-master]] (this is not relevant yet, as Jessie is the LTS release, while only dpkg from Stretch and newer produces .buildinfo files.)
Line 46: Line 52:
 * dpkg: some bug #xxx about gzip timestamps
 * dpkg: some other bug #xxx tar directory order
= Also related =
Line 49: Line 54:
== Different problems, and their solutions ==  * [[DebianBug:895346|#895346]] [devscripts] devscripts: dcmd --buildinfo is not documented
 * [[DebianBug:869567|#869567]] [devscripts] debsign: doesn't sign multiple .buildinfo in the same changes
 * [[DebianBug:898961|#898961]] [devscripts] dscverify: accept .buildinfo from a build with unsigned .dsc which later was signed
 * [[DebianBug:807270|#807270]] [devscripts] mk-origtargz: create reproducible tarballs and --mtime option
 * [[DebianBug:852365|#852365]] [sbuild] sbuild: append-to-version may overwrite incorrect .buildinfo
 * [[DebianBug:923987|#923987]] [sbuild] Should also send the buildinfo in the build mail
Line 51: Line 61:
=== Non-problems ===
Line 53: Line 62:
 * You might think ELF binaries (e.g. /usr/bin/hello in the hello package) have embedded timestamps. Luckily, they don't! There are many other possible nice-to-haves, e.g., making builds independent of their build directory, making it possible to create archive formats (like tar.gz and zip) with different tools yet result in the same byte order, etc. Many of those are valuable, but they shouldn't distract from getting the results of reproducible builds out to users.
Line 55: Line 64:
=== Data files in data.tar.gz have timestamps === = Even more =
Line 57: Line 66:
 * 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 more concrete tasks to be done, look at [[https://reproducible-builds.org/contribute/|how to contribute]].
Line 65: Line 68:
=== {data,control}.tar.{gz,xz,bz2} may have timestamps === [[https://reproducible.debian.net/userContent/unstable/amd64/stats_pkg_state.png|{{https://reproducible.debian.net/userContent/unstable/amd64/stats_pkg_state.png|Statistics from the continuous integration platform|width=100%}}|class=]]
Line 67: Line 70:
 * dpkg 1.17.1 might or might not store a timestamp for the .gz versions of these files.
 * *.xz and *.bz2 seem to provide no ability to store a timestamp.
----
Line 70: Line 72:
=== {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.

== References ==

* Mike Perry's discussion of how it took him eight weeks to make the Tor Browser Bundle have this feature: http://people.debian.org/~paulproteus/mike-perry-reproducible-tbb.txt
CategoryDeveloper CategoryPackaging

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

https://reproducible-builds.org

It should be possible to reproduce, byte for byte, every build of every package in Debian. More information about reproducible builds in general are available at reproducible-builds.org.

About
About

Howto
Make a package reproducible

Contribute
?How to help

Toolchain
Experimental toolchain

History
Project history

Salsa / Gitlab
Salsa project / Gitlab

Bugs
Bug reports

Jenkins
Continuous integration

Status

Reproducible builds of Debian as a whole is still not a reality, though individual reproducible builds of packages are possible and being done. So while we are making very good progress, it is a stretch to say that Debian is reproducible.

  • Most packages built in sid today are reproducible under a fixed build-path and environment.

  • We have a new control file *.buildinfo that records the build environment, see deb-buildinfo for reference. Older design drafts are here.

  • We have a continuous integration platform that builds and immediately rebuilds packages. With this we can detect problems related to timestamps, file ordering, CPU usage, (pseudo-)randomness and other things.

  • We are examining packages and sorting out common problems.

  • Many patches have already been submitted, and we are continuously writing new ones.

  • You can check which packages installed on your system are still unreproducible by using the reproducible-check script in the devscripts package.

Big outstanding issues

These are the critical items necessary to have reproducible builds for at least the required packages of Debian

Annoying but not major

Nice to have

  • Tighten up the Policy definition of "reproducible" to be stricter about environment variables and build paths.
  • Discuss which environment variables we should blacklist or whitelist, 876055.

  • #929397: ftp.d.o: please upload LTS .buildinfo files to ftp-master (this is not relevant yet, as Jessie is the LTS release, while only dpkg from Stretch and newer produces .buildinfo files.)

Also related

  • #895346 [devscripts] devscripts: dcmd --buildinfo is not documented

  • #869567 [devscripts] debsign: doesn't sign multiple .buildinfo in the same changes

  • #898961 [devscripts] dscverify: accept .buildinfo from a build with unsigned .dsc which later was signed

  • #807270 [devscripts] mk-origtargz: create reproducible tarballs and --mtime option

  • #852365 [sbuild] sbuild: append-to-version may overwrite incorrect .buildinfo

  • #923987 [sbuild] Should also send the buildinfo in the build mail

There are many other possible nice-to-haves, e.g., making builds independent of their build directory, making it possible to create archive formats (like tar.gz and zip) with different tools yet result in the same byte order, etc. Many of those are valuable, but they shouldn't distract from getting the results of reproducible builds out to users.

Even more

For more concrete tasks to be done, look at how to contribute.

Statistics from the continuous integration platform


CategoryDeveloper CategoryPackaging