Debian reproducibility statistics

Re:Debian reproducibility statistics by dozzie on Thursday August 24, 2017 @07:08AM (#15089107)

It's a term for binaries (usually ELF) being byte-to-byte equal in two different runs of a compiler. This way you can build a binary package from source package and if its content is the same, you know what source code was used to build the package, and then you can e.g. inspect the code for backdoors or build debug symbols without planning for that beforehand.

https://en.wikipedia.org/wiki/Reproducible_build

[ Parent | on HN ]

Re:Debian reproducibility statistics by 0xcde4c3db on Thursday August 24, 2017 @08:37AM (#15089558)

Debian seems to only considers a build reproducible if the entire .deb file is byte-for-byte identical, not just the ELF files. A bunch of the packages they're tracking are flagged for documentation files such as PDFs not coming out identical.

[ Parent | on HN ]

Re:Debian reproducibility statistics by dozzie on Thursday August 24, 2017 @08:39AM (#15089574)

Which for an OS distribution is a perfectly valid view point and a very noble goal.

[ Parent | on HN ]

Re:Debian reproducibility statistics by easytiger on Thursday August 24, 2017 @08:44AM (#15089604)

Lots of dates and build numbers, hashes and more get put in binaries let alone package files. How could they ever be b4b the same?

[ Parent | on HN ]

Re:Debian reproducibility statistics by geofft on Thursday August 24, 2017 @02:08PM (#15092509)

It's a good question! It's in fact such a good question that the reproducible builds folks had to draft a solution for it: the SOURCE_DATE_EPOCH specification. Reproducible builds read the timestamp of the last debian/changelog entry (you can imagine the last git commit or something, for non-Debian packages) and pass it through to the build system, so that the "current" time in tarballs etc. is actually the time of the changelog entry.

https://reproducible-builds.org/specs/source-date-epoch/

For things like build numbers, there's a tool called strip-nondeterminism that cleans them up:

https://packages.debian.org/sid/strip-nondeterminism

[ Parent | on HN ]

Re:Debian reproducibility statistics by perlgeek on Thursday August 24, 2017 @08:53AM (#15089672)

The "build number" is actually the version, which is determined from debian/changelog. A hash shouldn't change when its input doesn't change. Timestamps can be faked by intercepting system calls.

I'm sure there are many, many more techniques involved in making a build reproducible. Hey, they achieved >90% already!

[ Parent | on HN ]

Re:Debian reproducibility statistics by zimbatm on Thursday August 24, 2017 @10:14AM (#15090248)

The best approach that I have found is to use the git commit timestamp (or epoch 1 as a fallback) instead of the current timestamp. After all if the build is reproducible, it doesn't matter when it was built, only what input it was given.

To fix that kind of thing, patching is required.

[ Parent | on HN ]

Re:Debian reproducibility statistics by amaranth on Thursday August 24, 2017 @08:50AM (#15089640)

They just patch those out.

[ Parent | on HN ]

Re:Debian reproducibility statistics by gnasr on Thursday August 24, 2017 @08:06AM (#15089369)

And why Debian is not reproducible?

[ Parent | on HN ]

Re:Debian reproducibility statistics by 0x0 on Thursday August 24, 2017 @11:46AM (#15091053)

On almost any system, if you use a compiler to build a binary from source code twice in a row, you will get two different binaries. Simple things like using "__DATE__" and "__TIME__" macros in C, or the linker embedding a link timestamp in a executable file header, will trigger this even in the same environment. Moving between machines is even trickier, as __FILE__ and __DIR__ and a ton of other inputs conspire to create changes in the output.

It's hard work to set up a project where you can actually get exactly the same binary over and over again.

I think asking "why is Debian not reproducible" is missing the mark a little - when everything else (Windows, macOS, FreeBSD, etc etc etc) is probably not reproducible, the better question is perhaps "why is Debian trying to be reproducible, and why aren't other projects talking about this just as much" :)

[ Parent | on HN ]

Re:Debian reproducibility statistics by MrQuincle on Thursday August 24, 2017 @08:18AM (#15089444)

https://wiki.debian.org/ReproducibleBuilds

"With this we can detect problems related to timestamps, file ordering, CPU usage, (pseudo-)randomness and other things"

https://tests.reproducible-builds.org/debian/index_variation...

[ Parent | on HN ]

Re:Debian reproducibility statistics by wiz21c on Thursday August 24, 2017 @08:11AM (#15089396)

because during the compilation, some package use date-dependent stuff, for example (I dunno the exact details though)

[ Parent | on HN ]

Re:Debian reproducibility statistics by vertex-four on Thursday August 24, 2017 @08:20AM (#15089456)

Also some build systems create artifacts as a result of timing-dependent algorithms. Simply put, if two things A and B run simultaneously, and A completes before B, then in some compilers/build systems/etc the result can be different from B completing before A. GHC, as a well-known example, suffers from this problem.

[ Parent | on HN ]

Re:Debian reproducibility statistics by Daviey on Thursday August 24, 2017 @08:17AM (#15089436)

Often, package is built using a certain library version (from a different package), that library is then updated - and the new package cannot build using the new library.

Or... deeper parts of the compiler toolchain change, and the application doesn't re-build without changes.

[ Parent | on HN ]

Re:Debian reproducibility statistics by vertex-four on Thursday August 24, 2017 @08:22AM (#15089470)

That has nothing to do with reproducible builds - the issue being solved by reproducible builds is that even in exactly the same environment, running the same build script twice can result in differences in the output.

[ Parent | on HN ]

Re:Debian reproducibility statistics by noselasd on Thursday August 24, 2017 @10:16AM (#15090262)

Surely it can't have "nothing to do" ? Many debian source packages specifies dependencies using >= , something has to account for performing a build using the same minor version of such a dependency.

[ Parent | on HN ]

Re:Debian reproducibility statistics by vertex-four on Thursday August 24, 2017 @11:20AM (#15090812)

Yes, but that's a different problem from reproducible builds. The only thing that reproducible builds is solving is ensuring that the same package built with the same dependencies in the same environment results in the same output.

[ Parent | on HN ]

Re:Debian reproducibility statistics by cstrahan on Friday August 25, 2017 @11:47AM (#15099318)

I'm afraid you're mistaken.

Taken directly from https://reproducible-builds.org/:

"Second, the set of tools used to perform the build and more generally the build environment should either be recorded or pre-defined"

FWIW, I'm a committer on a Linux distro specifically constructed to guarantee build reproducibility (nixos.org), so I'm pretty sure I know what is generally meant by "reproducible builds" in common industry vernacular. Byte-for-byte is important, but that's hardly the whole picture.

[ Parent | on HN ]

Re:Debian reproducibility statistics by wtallis on Thursday August 24, 2017 @10:39AM (#15090436)

If the dependency is packaged separately, then you typically wouldn't expect minor version changes in the dependency to affect the contents of the package being built. If there are major changes to the header files being exported or if there's static linking involved then changes are to be expected. But if not, you'd expect the changes to show up in the dynamically linked process image, not the on-disk package.

[ Parent | on HN ]

Re:Debian reproducibility statistics by noselasd on Thursday August 24, 2017 @02:00PM (#15092457)

It really doesn't take big changes to a library that makes the relocation table of an executable linking to it be a tad different

[ Parent | on HN ]

Re:Debian reproducibility statistics by talaketu on Thursday August 24, 2017 @09:00PM (#15095367)

hermetic build is part of reproducible build, as far as the general concepts go.

[ Parent | on HN ]