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?

mYnDstrEAm
  • 4,275
  • 14
  • 57
  • 118

1 Answers1

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.

Stephen Kitt
  • 434,908
  • 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 08 '21 at 09: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. – Stephen Kitt Oct 08 '21 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 08 '21 at 17:29
  • The reproducible builds project checks that packages build the same when hardware changes, or various aspects of the build environment change. When I mention the build context, I mean the set of packages installed to build the package itself, i.e. everything that ends up tracked in the buildinfo files. It’s expected that package builds vary when the build context varies. Since packages are built in unstable, and unstable is constantly changing, you can’t build packages at different times and expect to get the exact same output. – Stephen Kitt Oct 08 '21 at 21:03
  • But once a package is built, it never changes; so as far as integrity goes, you only ever need to check your local hash against the hash in the repository. Constantly checking the hash against packages rebuilt by the reproducible builds project provide any additional integrity. It wouldn’t work anyway, because the original build environment isn’t reproduced in the reproducible builds setup. – Stephen Kitt Oct 08 '21 at 21:05
  • 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. – Stephen Kitt Oct 08 '21 at 21:07
  • I think it would be good if there was automated building and hashing of packages with the same build environment as in the latest Debian stable (which gets rerun whenever related packages change / there is an dist-upgrade). Furthermore, it may be possible and good to prevent there not being the exact same output after related packages change (or at least not as often; there probably isn't that much benefits in what's causing the small differences). When only checking your local hash against hash in repo there still is a disconnect between what is in repo & what is verified as reproducible. – mYnDstrEAm Oct 09 '21 at 08:03
  • 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). – Stephen Kitt Oct 09 '21 at 09:46