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

1–10 of 72 posts

Re: Debian reproducibility statistics

#3

Post by dozzie »

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

Re: Debian reproducibility statistics

#4

Post by gnasr »

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

And why Debian is not reproducible?

Re: Debian reproducibility statistics

#5

Post by wiz21c »

gnasr wrote: post #4
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

And why Debian is not reproducible?

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

Re: Debian reproducibility statistics

#7

Post by Daviey »

gnasr wrote: post #4
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

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.

Re: Debian reproducibility statistics

#8

Post by MrQuincle »

gnasr wrote: post #4
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

And why Debian is not reproducible?

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...

Post reply on HN