Making reproducible builds & GitBOM work together in spite of low-level component variation

[Vagrant Cascadian]

On 2022-06-24, David A. Wheeler wrote:
>> On Jun 22, 2022, at 2:28 PM, Vagrant Cascadian <vagrant at reproducible-builds.org> wrote:
> Fair enough. Let's use Debian as an example. The "typical"
> way I've seen Linux kernel headers installed would be by running:
>
>> sudo apt install linux-headers-$(uname -r)
>
> This command would *NOT* work any more with reproducible builds if GitBOM is used
> and the kernel is updated. Even if the headers don't change the resulting
> *executable* code, the GitBOM hashes would. be recorded in the resulting
> compiled objects (e.g., ELF files), and they would be *different*. What's more,
> since the GitBOMs are transitive, all the generated executables would be transitively different.
>
> The solution is either to run on the same old kernel (e.g., in a VM), or to install
> the linux-headers-VERSION for the build being reproduced (NOT for the actual running kernel).
> The latter *does* work fine for a container (as I noted earlier).

Right.

The only issue I see is if you're somehow guessing about the header
files to use from the running kernel (e.g. "uname -r"), rather than
using the information present in your build metadata (e.g. .buildinfo,
GitBOM, etc.) ... you need to consistently install the same packages
and/or files in your build environment to get something to consistently
build reproducibly.

In general, this is accomplished with chroots, containers or virtual
machines purpose-built to only contain the packages and/or files needed.

Obviously this only works if your build environment is completely set up
before the build process starts; if the build process downloads stuff
from the network, all manner of non-determinism can work into the
builds!


Do you have another concrete example of something that might get
inferred, rather than explicitly defined in the GitBOM? It would seem a
bug in the build process to have implicit inputs rather than explicit
ones.


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20220624/dcef7a5f/attachment.sig>