Lots of progress for Debian's reproducible builds • Hacker News Board

Re: Lots of progress for Debian's reproducible builds

#11

Post by csirac2 » Tue, Jan 27, 2015, 3:18 AM UTC

chubot wrote: post #5

I actually did some work making debootstrap reproducible. So even if the 100 or so .deb builds it depends on are reproducible, then the chroot image resulting from debootstrap will not be reproducible byte-for-byte, due to the debootstrap shell script itself and the tools it calls. Offhand, I remember that /etc/{passwd,group} are copied from the host machine by design. There is also a random seed file, to save entrop…

I'm interested! I actually have had to work around the /etc/{passwd,group} shenanigans for other reasons, interested to see what you did there.

Re: Lots of progress for Debian's reproducible builds

#12

Post by xai3luGi » Tue, Jan 27, 2015, 4:01 AM UTC

chubot wrote: post #5

I actually did some work making debootstrap reproducible. So even if the 100 or so .deb builds it depends on are reproducible, then the chroot image resulting from debootstrap will not be reproducible byte-for-byte, due to the debootstrap shell script itself and the tools it calls. Offhand, I remember that /etc/{passwd,group} are copied from the host machine by design. There is also a random seed file, to save entrop…

Debian appears to be doing some work on that too:

https://wiki.debian.org/ReproducibleInstalls

Re: Lots of progress for Debian's reproducible builds

#13

Post by walterbell » Tue, Jan 27, 2015, 4:09 AM UTC

desdiv wrote: post #9

walterbell wrote: post #3

Baserock ( http://wiki.baserock.org ) may have a repeatable build of OpenEmbedded for automotive systems.

What's the relationship between Baserock and OpenEmbedded? Glancing through OpenEmbedded's wiki page, it seems to a recipe/build system for embedded linux. Baserock seems to be in the same league.

It's a distro/downstream stable version of OE, used in automotive, http://www.genivi.org/. There are several OE "distros", e.g. Angstrom, http://www.angstrom-distribution.org/ . There's also Yocto, the overall build system, https://www.yoctoproject.org/

Re: Lots of progress for Debian's reproducible builds

#14

Post by Alupis » Tue, Jan 27, 2015, 5:00 AM UTC

Can anyone comment on why all builds are not currently "reproducible"?

I mean, if a package is compiled on the same system, with the same compiler, with the same build script -- should it not produce the same output?

Re: Lots of progress for Debian's reproducible builds

#15

Post by detaro » Tue, Jan 27, 2015, 5:09 AM UTC

Alupis wrote: post #14

Can anyone comment on why all builds are not currently "reproducible"? I mean, if a package is compiled on the same system, with the same compiler, with the same build script -- should it not produce the same output?

For a few examples, see the third paragraph of the article. Things like filesystem ordering, system time, ...

Also, the goal is to make it reproducible across machines, since one of the motivations is to enable everybody to verify that the binary distribution matches the source.

Re: Lots of progress for Debian's reproducible builds

#16

Post by agwa » Tue, Jan 27, 2015, 5:15 AM UTC

Alupis wrote: post #14

Can anyone comment on why all builds are not currently "reproducible"? I mean, if a package is compiled on the same system, with the same compiler, with the same build script -- should it not produce the same output?

The biggest offender is timestamps - compiled binaries, documentation, archives, etc. often contain the time at which the file was built.

Other problems include non-deterministic filesystem order, randomized hash algorithms, and even the fact that Markdown processors mangle email addresses randomly. A highly vexing problem that I'm currently trying to solve is that libxslt implements the XSLT generate-id() function by taking the memory address of the XML node struct, which makes documentation generated with XSLT non-reproducible (memory addresses are non-deterministic because of address space randomization and randomized hash tables).

(I'm the author of strip-nondeterminism, a tool in our custom toolchain that attempts to normalize files after they're built.)

Re: Lots of progress for Debian's reproducible builds

#17

Post by jml7c5 » Tue, Jan 27, 2015, 5:18 AM UTC

Will this provide a guaranteed method for reproducible builds, or will it still be technically possible to create build scripts that produce different results (e.g., by pulling from /dev/random, or grabbing timing information from various sources, or by writing a multithreaded program whose threads all write to a single file)?

Re: Lots of progress for Debian's reproducible builds

#18

Post by contingencies » Tue, Jan 27, 2015, 6:48 AM UTC

agwa wrote: post #16

Alupis wrote: post #14

Can anyone comment on why all builds are not currently "reproducible"? I mean, if a package is compiled on the same system, with the same compiler, with the same build script -- should it not produce the same output?

The biggest offender is timestamps - compiled binaries, documentation, archives, etc. often contain the time at which the file was built. Other problems include non-deterministic filesystem order, randomized hash algorithms, and even the fact that Markdown processors mangle email addresses randomly. A highly vexing problem that I'm currently trying to solve is that libxslt implements the XSLT generate-id() function b…

strip-nondeterminism "is a Perl module for stripping bits of non-deterministic information, such as timestamps and file system order, from files such as gzipped files, ZIP archives, and Jar files. It can be used as a post-processing step to make a build reproducible, when the build process itself cannot be made deterministic. It is used as part of the Reproducible Builds project."

Browse source @ https://anonscm.debian.org/cgit/reproducible/strip-nondeterm...

PS. non-deterministic filesystem order .. doesn't this go away if you use tmpfs?

Re: Lots of progress for Debian's reproducible builds

#19

Post by contingencies » Tue, Jan 27, 2015, 6:55 AM UTC

walterbell wrote: post #13

desdiv wrote: post #9

Earlier quoted context omitted.

What's the relationship between Baserock and OpenEmbedded? Glancing through OpenEmbedded's wiki page, it seems to a recipe/build system for embedded linux. Baserock seems to be in the same league.

It's a distro/downstream stable version of OE, used in automotive, http://www.genivi.org/ . There are several OE "distros", e.g. Angstrom, http://www.angstrom-distribution.org/ . There's also Yocto, the overall build system, https://www.yoctoproject.org/

I drank with the Yocto people in 2011. They absolutely live and breathe release engineering. On subjects like repeatable builds, I trust their opinion. At present, they don't appear to mention it at all on their docs or wiki.

Re: Lots of progress for Debian's reproducible builds

#20

Post by jzwinck » Tue, Jan 27, 2015, 7:35 AM UTC

agwa wrote: post #16

Alupis wrote: post #14

Can anyone comment on why all builds are not currently "reproducible"? I mean, if a package is compiled on the same system, with the same compiler, with the same build script -- should it not produce the same output?

The biggest offender is timestamps - compiled binaries, documentation, archives, etc. often contain the time at which the file was built. Other problems include non-deterministic filesystem order, randomized hash algorithms, and even the fact that Markdown processors mangle email addresses randomly. A highly vexing problem that I'm currently trying to solve is that libxslt implements the XSLT generate-id() function b…

Maybe you could fix the libxslt problem by using a pool allocator for the nodes. The pool would contain only the nodes, and you could use the offset in the pool as their ID, rather than the full virtual address. Just some food for thought.