I wonder if Canonical (and/or Debian) provide any sort of guarantee that all packages in main and universe repos are always either built from source by themselves, or verified by them (in case of deterministic or signed reproducible builds) as opposed to just including binaries compiled by others (which implies that you have to trust them, as well, to not be doing something shady or unclear on their compilation process, or using anything outside the public source repo other than private keys for signing, where applicable).

What are Debian and Ubuntu's policies on this? Do they have any official pages or statements on this matter? I'd expect them to do it at least for main, but what about universe? Who am I "trusting" (to provide what they claim to have compiled) when I install something from universe? Just Canonical/Debian or also the authors themselves?

Related: (some info I found on reproducible builds, mostly old)

  • 7
    Careful about using the word "guarantee" in a casual sense; you really seem to be asking about policy (which can have exceptions). Canonical provides no guarantee to non-customers.
    – user535733
    Feb 16, 2021 at 22:11
  • Somewhat related: askubuntu.com/a/52882
    – geekley
    Feb 16, 2021 at 22:21
  • BTW, what about open-source/free-software snaps? Are they curated or built from source by the Ubuntu Team? I assume they're not, right? It does seem like they manually review --classic snaps, but the review process doesn't seem to mention or require any access to source code (and it seems like the review is done once, not on every version).
    – geekley
    Feb 17, 2021 at 0:14
  • 2
    The answer to your BTW is non-trivial, and irrelevant to the question you asked, Please open a new question for new questions. This is not a threaded forum.
    – user535733
    Feb 17, 2021 at 0:49
  • Somewhat related: opensource.stackexchange.com/questions/10974/…
    – geekley
    Nov 2, 2022 at 20:28

3 Answers 3


Packages in main and universe are built in the launchpad build farm, from source. You don't need to ask for verification of this as you can find it yourself.

For example, at the time of writing the most recent build of bind uploaded to Ubuntu 20.04 LTS (Focal) is 1:9.16.1-0ubuntu2.5. You can see this via the focal-changes public mailing list. Specifically this post which links to launchpad where you can see the source files and builds, and build logs for every supported architecture. For example the amd64 build for that version of that package is found here with the build log here.

You can repeat this process for every package in every release of Ubuntu.

While I mentioned main and universe, the same is true of restricted and multiverse packages, which are also built on launchpad. However they may contain non-free components, so aren't guaranteed to be built "from source", but there is a source package for each, even if it contains some binary components.

  • 1
    Ah, cool! Thanks for the explanation! I didn't know they published the build logs as well. That's great to know!
    – geekley
    Feb 16, 2021 at 21:14
  • Glad it was helpful. You can even watch the builders while they build. It's quite fun and nerdy to watch other people's stuff building. launchpad.net/builders
    – popey
    Feb 16, 2021 at 21:16
  • Do they also include signed open-source binaries from third-parties and perform reproducibility verification? Or do they just compile everything open-source themselves and sign it themselves?
    – geekley
    Feb 16, 2021 at 21:18
  • I believe the existing answers you've already found from experts like Colin Watson, are still valid and accurate.
    – popey
    Feb 16, 2021 at 21:21

From the Debian perspective: all packages are built on our dedicated servers (buildd's). Packages that are not built on the buildd's are not allowed to move into Testing and get into a stable release. Furthermore, every package built since about 2018 includes a .buildinfo file: while this doesn't guarantee reproducible builds, it does enable them. All packages in Bullseye have this file, thanks to a recent effort by a Debian developer to trigger those rebuilds for rarely-updated packages (eg, font packages).

As a whole, the folks at Debian are big fans of reproducible builds, and a lot of the people pushing them are part of the project. Tools for build reproducibility are integrated into the infrastructure: for instance, packages will typically be built with standardized timestamps, and will soon be built with standardized locations.


The simplistic answer is that the packages in Ubuntu are always built on Ubuntu auto-builders from source packages in the archive. Debian until recently allowed binary packages built by individual maintainers to enter testing and ultimately stable, that is no longer allowed since testing migration reopened for the bullseye cycle, but Debian developers are still permitted and in some cases required to upload binary packages to unstable. Ubuntu is much stricter on the introduction of external binaries.

However the simplistic answer leaves a few gaps open.

Firstly there is no technical measure to guarantee that the materials used from a source-package are actually source code. Indeed there can't be because the understanding of the term "source code" in the Debian community is more akin to the GPL definition than the traditional definition and hence depends more on how a file is created and maintained than what format it is in.

Secondly the content of a Debian binary package depends not just on the source package, but on the environment it is built in. That environment is formed by installing binary packages.

Which brings us on to the issue that some programs require themselves to build. gcc, glibc, binutils, make etc require gcc, glibc, binutils, make etc. rust requires rust. freepascal requires freepascal. golang is normally built with golang (it claims to also be build-able with gccgo but when I've tried, it didn't actually work).

Most of the time this is dealt with by using the previous version to build the next, but sometimes things go wrong and it becomes impossible to build one of these packages in the normal way because the existing version of the package is too broken on one or more architectures.

Sometimes maintainers will work around this by including bootstrapping binaries as part of the source package. Other times the packages in the archive will be re-bootstrapped with manually built binary packages. In debian this is normally done by the developer simply uploading the binary packages to the archive, then following up with a source upload to force a rebuild on the autobuilders. In Ubuntu I'm not sure exactly what the procedure is but I do know that only a relatively small number of people have permission to do it.

  • Very interesting points! Thanks!
    – geekley
    Feb 18, 2021 at 18:09

You must log in to answer this question.

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