Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian reproducibility statistics

tests.reproducible-builds.org

Post reply on HN
Print view View original

11–20 of 72 posts

Re: Debian reproducibility statistics

#11

Post by vertex-four »

wiz21c wrote: post #5
gnasr wrote: post #4

Earlier quoted context omitted.

And why Debian is not reproducible?

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

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.

Re: Debian reproducibility statistics

#12

Post by vertex-four »

Daviey wrote: post #7
gnasr wrote: post #4

Earlier quoted context omitted.

And why Debian is not reproducible?

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.

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.

Re: Debian reproducibility statistics

#13

Post by kalmi10 »

hmmm___food wrote: post #10

Maybe im missing something but it seems the justification behind this is based on a situation in which source wasnt open. Debian is open so why is reproducibility a priority?

So that anyone can check whether a binary (on the mirrors) has been tampered with in ways that are not present in the source.

Re: Debian reproducibility statistics

#15

Post by yakubin »

hmmm___food wrote: post #10

Maybe im missing something but it seems the justification behind this is based on a situation in which source wasnt open. Debian is open so why is reproducibility a priority?

On the contrary. Reproducibility means that given the source you are able to produce the exact same binary, i.e. you can verify that someone didn't modify it before building. When software isn't open, then reproducibility is meaningless, because you don't have the source, so: 1. you can't verify anything (you can't compile anything); 2. assurance of the binary not being modified gives you nothing, since you don't know if there is no malicious code in the original source code.

Re: Debian reproducibility statistics

#17

Post by 0xcde4c3db »

dozzie wrote: post #3
bialpio wrote: post #2

Can someone shed some light on what exactly "reproducible" means in this context?

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

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.

Re: Debian reproducibility statistics

#18

Post by dozzie »

0xcde4c3db wrote: post #17
dozzie wrote: post #3

Earlier quoted context omitted.

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

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.

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

Re: Debian reproducibility statistics

#19

Post by easytiger »

0xcde4c3db wrote: post #17
dozzie wrote: post #3

Earlier quoted context omitted.

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

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.

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?
Post reply on HN