1

Why reproducible builds are important is explained at reproducible-builds.org:

Whilst anyone may inspect the source code of free and open source software for malicious flaws, most software is distributed pre-compiled with no method to confirm whether they correspond.

This incentivises attacks on developers who release software, not only via traditional exploitation, but also in the forms of political influence, blackmail or even threats of violence.

According to isdebianreproducibleyet.com Debian is currently only 94.7% reproducible.

Packages in buster/amd64 which failed to build reproducibly are listed here.

Is there a simple and fast way to list all unreproducible packaged installed on the system?

I'm thinking of something like debsecan | grep "remotely exploitable" for identifying installed packages with vulnerabilities or vrms for making sure no packages which aren't free, open source software are installed. Does such a tool or script exist?

1 Answer 1

2

It’s important to note that the results shown in the reproducible builds information only reflect the theoretical reproducibility in the current testing framework. They can’t necessarily be translated in statements on the reproducibility of the packages currently downloadable from the Debian repositories.

That said, the devscripts package includes a reproducible-check command whose aim is similar to what you’re looking for: it downloads the current results from the CI infrastructure, and compares that to the set of installed packages. However it is currently somewhat buggy, and the test results are only exported for Bullseye... Keep an eye on the upstream repository if you’re interested, the tool is being worked on.

8
  • reproducible-check -r prints the plain list of (the many) packages in Debian 11. I think hashsums could be used to verify that the theoretical results match the real situation and this could be integrated into package managers like KDE's Discover and Apper and apt-get. The script should obviously also display installed packages that it found to not match what is reproducible as warnings and run regular scans in the background.
    – mYnDstrEAm
    Oct 8, 2021 at 9:31
  • I’m not sure I understand what you want to achieve by comparing hashes. You can check hashes against those published with packages in the repo, regardless of whether they’re reproducible; that’s what apt does already. Any results from the reproducible builds project aren’t generally applicable to packages published in the repositories, because the build context isn’t the same: the fact that a package is reproducible only means that, all else being equal, building the package twice will produce the same binaries. But all else isn’t equal. Oct 8, 2021 at 10:03
  • The hashes of "packages published in the repositories" could be compared to hashes of the results from the reproducible builds project. In addition, it seems like there need to be ways by which the exact same binaries (hashes) are produced in all build contexts. I'm not sure which conditions are currently hindering that (and if there's a page about this) but maybe (as example) it would mean that eg if certain hardware or config initial contexts would result in different binaries, compilers should instead build a condition-query/setting that make that built code not execute in the environment
    – mYnDstrEAm
    Oct 8, 2021 at 17:29
  • 1
    The point of a reproducible package is that, if you recreate the same build environment, you get the same result. This isn’t useful day-to-day, but it means that you can be more confident that the published source code really matches the published binaries. Oct 8, 2021 at 21:07
  • 1
    I don’t think there’s any point in continuing the debate here; please discuss your ideas with the Reproducible Builds project and consider contributing to the Debian reproducibility efforts (item 8 in the list of tasks is perhaps closest to what you’re interested in). Oct 9, 2021 at 9:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .