Gothenburg 2026 - Day 4 - dpkg and .buildinfo files

IRC meeting with the dpkg maintainer

• meetbot log of the discussion

the content of the pad we prepared for the discussion:

R-B problem description:

• p#1 The buildinfo files that are used as build inputs and outputs do not exactly identify the build dependencies.
  • For buildinfo as a build input this means that a rebuilder needs to resolve the package/version/architecture tuple to the snapshot providing it before starting the build, which involves a non-necessary dependency on such mapping, making the process more complex than it needs to be.
• p#2 For buildinfo as a build output this means that one cannot reliably tell which exact packages were used to provide the given build artifact; while package/version/architecture tuple is supposed to be unique in 99+% cases for Debian archives, that does not hold in a selection of corner cases, and is not prevented by auditable automation.
  • Both of those would be greatly aided if dpkg would store a reasonable hash of the installed .deb and would write it in dpkg-genbuildinfo.pl
• p#3 If we ever need to rotate the Debian archive signing key, we are still bound to use the old Debian snapshot signature, that was issued by a now-untrusted key. There have been suggestions during the summit to use some OpenTimestamps to work around this issue (essentially keeping old signatures trusted, that have been recorded in the bitcoin blockchain before some cut-off date (but we would rather not)). With hashes we have explicit pins about the packages needed.

Other problems:

• p#4 dpkg database does not store/provide precise information on the version of .deb files installed within Debian for when the policy of uniqueness is violated, and outside of a defined archive (such as Debian) where such policy does not exist.

Thus we propose to store the checksums (at least sha256) of the .deb files installed in the dpkg database, and provide them as part of the buildinfo files if they are present.

Recording sha256 may probably be optional if the hash were to be computed by dpkg, given the computation speed on big packages or many packages is a reasonable concern.

Possible solution paths for storing the hash in the dpkg database:

• #1 The caller (e.g. APT) has an option to provide the supposed hashsum on installation. This solution has the following properties:
  • dpkg would store and distribute information not verified by dpkg
  • Performance overhead is likely negligible, as the wrapping package managers are likely to compute checksums on download.
  • Whether to require the hash is not a concern of dpkg, can be granularly controlled by the wrapper.
• #2 dpkg (configurably? debconf/apt.conf.d option as we don’t control the dpkg command line but apt does, or dpkg.cfg) calculates the hashsum (-s?) of the .deb archive (around/in the process_archive function?). This has the following properties:
  • dpkg can guarantee that whatever it has been asked to install had the given checksum (note, that no claim is made around the filesystem state).
  • Package installs will get an overhead of hash calculation (this should acceptable for reproducible builds / buildd purposes, but may not be for other).
  • dpkg owns the definition and implementation of the checksums provided.
• #3 An alternative implementation of the database can be built outside of dpkg effectively re-implementing parts or the entirety of dpkg for the use-cases where the user would need stronger claims on the software installed. This has the following properties:
  • This is much more heavy of a change than the other options.
  • This gives the r-b effort more fine-tuned solution, that can be controlled without changes to the core component of Debian.
  • May be extended to provide an alternative package manager for Debian and derivative systems.
  • Will provide a second verification toolchain for at least some of the build pipeline, additionally enhancing reproducibility claims.

Possible solution paths without support in the core dpkg:

• User-provided mapping for dpkg-genbuildinfo.pl to use.
• User-provided dpkg-genbuildinfo.pl that gets the hash information around dpkg (from user-provided mapping or from APT/other wrappers).