11 ms·

> Even if somebody links a package to their Git repo, who knows what commit correlates to a given release? Even if somebody pushes a "tag" for the release, ther

> Even if somebody links a package to their Git repo, who knows what commit correlates to a given release? Even if somebody pushes a "tag" for the release, there is still no guarantee that it's actually the same code That's not what reproducible means in this context. Being able to go from a given release artifact to a git repo is not what the "reproducible builds" project/movement/whatever is about. Reproducible builds are more about the packaging of something than about specific language ecosystems, so asking about languages that focus on reproducible builds makes less sense than asking about package ecosystems, build systems, and linux distros that do. Let's look at an example: docker is written in go, and is marked as reproducible in debian, but unreproducible in archlinux: https://ismypackagereproducibleyet.org/?pkg=docker&query=query https://ismypackagereproducibleyet.org/?pkg=docker&query=que... (named docker.io on debian https://ismypackagereproducibleyet.org/?pkg=docker.io&query=query https://ismypackagereproducibleyet.org/?pkg=docker.io&query=...) Why is that? Well, debian sets the "version.BuildTime" option when it compiles it to a constant value each time it compiles it: https://salsa.debian.org/go-team/packages/docker/-/blob/4f1ff0d78a665f1893e329a6ea892dd755f9dffc/debian/rules#L46 https://salsa.debian.org/go-team/packages/docker/-/blob/4f1f... Archlinux's PKGBUILD doesn't https://github.com/archlinux/svntogit-community/blob/cf04bef9069afe742adc97f44e91654e80bcd829/trunk/PKGBUILD#L91-L94 https://github.com/archlinux/svntogit-community/blob/cf04bef... Because of that, "docker version" on arch linux outputs that it was built on the actual day it was built, whenever that was, and each time it's built that string changes. Hence, not reproducible. Reproducible builds are about capturing enough information about how something is built, and specific enough build instructions, that two people can produce the same bit-for-bit identical output, and therefore verify that someone didn't compile a malicious backdoored binary, and also increase the chance that each build consistently works or doesn't work, regardless of who compiles it when.

pabs3 4y ago
Your last paragraph sounds like something that the GP poster seems to want from NPM. The NPM packages are downstream pre-built packages created (hopefully) from upstream git tags, but currently nothing verifies that and few people seem to care.
KronisLV 4y ago
> Well, debian sets the "version.BuildTime" option when it compiles it to a constant value each time it compiles it: https://salsa.debian.org/go-team/packages/docker/-/blob/4f1f https://salsa.debian.org/go-team/packages/docker/-/blob/4f1f... I feel like I understand why this is done, but it still feels extremely odd. We're making tools and such lie to us in the pursuit of reproducibility and oftentimes this means erasing certain information, that we might be interested in actually keeping! Surely, we should be able to do better than that, something like: /my-package /reproducible [CONSISTENT_BUILD_OUTPUT_FOR_CODE_INPUT] /non-reproducible build-time.txt build-system-information.txt build-log-with-timestamps.txt build-package-mirrors-that-were-contacted.txt build-step-timing-information-and-traces.txt [OTHER_STUFF_GOES_HERE] Of course, I don't think I can answer the question for where information like this should go for every tech stack and package type out there. That said, it's absolutely annoying to build a container image with Jib (just an example from when I last tried) and then see in Docker that its build time was supposedly decades ago. While having incorrect timestamps isn't the worst thing ever, I can imagine other pieces of information mattering more.
- Hizonner 4y ago
  If you have reproducible binaries, then you don't care about the build time, because all builds of the same version will be identical, regardless of when they were made. The simpler solution is to leave the build time out of the binary/package/whatever entirely.
Foxboron 4y ago
> Archlinux's PKGBUILD doesn't https://github.com/archlinux/svntogit-community/blob/cf04bef https://github.com/archlinux/svntogit-community/blob/cf04bef... > Because of that, "docker version" on arch linux outputs that it was built on the actual day it was built, whenever that was, and each time it's built that string changes. Hence, not reproducible. Fwiw, I'm the maintainer of Docker on Arch and this is a bit more complicated. Arch doesn't need to care about build time because `pacman` sets `SOURCE_DATE_EPOCH` during package building which is then utilized by the docker build system. https://github.com/moby/moby/commit/760763e9957840f1983a5006f4e66d6920ec496e https://github.com/moby/moby/commit/760763e9957840f1983a5006... If you look at the diff from an actual reproduction of the `docker` package (the Debian Reproducible Builds CI is a fuzzer), you will see there is no issues around build time. https://reproducible.archlinux.org/api/v0/builds/359851/diffoscope https://reproducible.archlinux.org/api/v0/builds/359851/diff... What you do see is some weird differences around `NT_GNU_BUILD_ID` and `GO BUILDID`. This is because of `lto`. In Arch we try to build most Go packages with cgo for the purpose of utilizing hardening flags. The issue is that the C code generation in Golang isn't actually reproducible with `lto` enabled. One issue is what I submitted here; https://github.com/golang/go/pull/53528 https://github.com/golang/go/pull/53528 Another issue which I have been trying to debug is why the code snippet located here doesn't reproduce. https://pub.linderud.dev/cg/ https://pub.linderud.dev/cg/ This results in the BUILDID generated and sat by the cgo build process isn't reproducible. I could disable lto and all the binary hardening and docker would probably be reproducible, but where is the fun in that :)?
- TheDong 4y ago
  Neat, thanks for the explanation and links! Sorry for being so off the mark there for your package, though my incorrect understanding I think did allow for a good explanation of what reproducibility is about and one thing that commonly fails!
  - Foxboron 4y ago
    No worries :) I should blog more about these things so people do get better insight into obscure issues like the one above.

pabs3 4y ago

Your last paragraph sounds like something that the GP poster seems to want from NPM. The NPM packages are downstream pre-built packages created (hopefully) from upstream git tags, but currently nothing verifies that and few people seem to care.

KronisLV 4y ago

> Well, debian sets the "version.BuildTime" option when it compiles it to a constant value each time it compiles it: https://salsa.debian.org/go-team/packages/docker/-/blob/4f1f https://salsa.debian.org/go-team/packages/docker/-/blob/4f1f... I feel like I understand why this is done, but it still feels extremely odd. We're making tools and such lie to us in the pursuit of reproducibility and oftentimes this means erasing certain information, that we might be interested in actually keeping! Surely, we should be able to do better than that, something like: /my-package /reproducible [CONSISTENT_BUILD_OUTPUT_FOR_CODE_INPUT] /non-reproducible build-time.txt build-system-information.txt build-log-with-timestamps.txt build-package-mirrors-that-were-contacted.txt build-step-timing-information-and-traces.txt [OTHER_STUFF_GOES_HERE] Of course, I don't think I can answer the question for where information like this should go for every tech stack and package type out there. That said, it's absolutely annoying to build a container image with Jib (just an example from when I last tried) and then see in Docker that its build time was supposedly decades ago. While having incorrect timestamps isn't the worst thing ever, I can imagine other pieces of information mattering more.

Hizonner 4y ago
If you have reproducible binaries, then you don't care about the build time, because all builds of the same version will be identical, regardless of when they were made. The simpler solution is to leave the build time out of the binary/package/whatever entirely.

Foxboron 4y ago

> Archlinux's PKGBUILD doesn't https://github.com/archlinux/svntogit-community/blob/cf04bef https://github.com/archlinux/svntogit-community/blob/cf04bef... > Because of that, "docker version" on arch linux outputs that it was built on the actual day it was built, whenever that was, and each time it's built that string changes. Hence, not reproducible. Fwiw, I'm the maintainer of Docker on Arch and this is a bit more complicated. Arch doesn't need to care about build time because `pacman` sets `SOURCE_DATE_EPOCH` during package building which is then utilized by the docker build system. https://github.com/moby/moby/commit/760763e9957840f1983a5006f4e66d6920ec496e https://github.com/moby/moby/commit/760763e9957840f1983a5006... If you look at the diff from an actual reproduction of the `docker` package (the Debian Reproducible Builds CI is a fuzzer), you will see there is no issues around build time. https://reproducible.archlinux.org/api/v0/builds/359851/diffoscope https://reproducible.archlinux.org/api/v0/builds/359851/diff... What you do see is some weird differences around `NT_GNU_BUILD_ID` and `GO BUILDID`. This is because of `lto`. In Arch we try to build most Go packages with cgo for the purpose of utilizing hardening flags. The issue is that the C code generation in Golang isn't actually reproducible with `lto` enabled. One issue is what I submitted here; https://github.com/golang/go/pull/53528 https://github.com/golang/go/pull/53528 Another issue which I have been trying to debug is why the code snippet located here doesn't reproduce. https://pub.linderud.dev/cg/ https://pub.linderud.dev/cg/ This results in the BUILDID generated and sat by the cgo build process isn't reproducible. I could disable lto and all the binary hardening and docker would probably be reproducible, but where is the fun in that :)?

TheDong 4y ago
Neat, thanks for the explanation and links! Sorry for being so off the mark there for your package, though my incorrect understanding I think did allow for a good explanation of what reproducibility is about and one thing that commonly fails!
- Foxboron 4y ago
  No worries :) I should blog more about these things so people do get better insight into obscure issues like the one above.