Call for real-world scenarios prevented by RB practices

[Richard Purdie]

Hi,

On Tue, 2022-03-22 at 12:46 +0000, Chris Lamb wrote:
> Just wondering if anyone on this list is aware of any real-world
> instances where RB practices have made a difference and flagged
> something legitimately "bad"?
> 
> Pretty sure that everyone here believes that reproducible builds *can*
> detect such issues (and might even prevent them from being attempted
> in the first place), but would be interested in anything that has been
> made public that can be specifically credited to reproducible builds
> practices or similar.

As we underwent this work with Yocto Project (which cross compiles), the biggest
thing we found were floating dependencies, for example where code would change
configuration depending on whether the host has /usr/bin/sendmail or not.

A second class of issues for us were build paths leaking into output binaries.
Our reproducible build tests always build in two different locations so we're
pretty happy to have that class of issues resolved now.

I pulled out a few random examples of things we've fixed:

A fun rpm issue where rpms built on an aarch64 host differed from those built on
an x86_64 system:

https://git.yoctoproject.org/poky/commit/?id=d441b484ebb4cdde228cedb3378019ffbdc391ac

Broken file ownership in output packages from build races:

https://git.yoctoproject.org/poky/commit/?id=fb1fe1a60d93eb05010c7b6a8077eddd4f910e95

gtk+3 shipping a file but also sometimes regenerating it during build:

https://git.yoctoproject.org/poky/commit/?id=df2c56f4d55d5edce77548cde0e1dc4d83503844

Makefile globing leading to varying binary output:

https://git.yoctoproject.org/poky/commit/?id=2aac5700b80f8e207db0a212d97dd9a650151dc7

Host paths to grep/python leaking into the output:

https://git.yoctoproject.org/poky/commit/?id=fe8c75f72e1a75c2f964e1e41c3dad84a6b87c38

Sendmail path issue example:

https://git.yoctoproject.org/poky/commit/?id=9f0b69e91c51bad8722e765df95b545e3ecec9b1

Most of these aren't malicious but they are "bad" in the sense that we wanted to
identify and fix them.

Cheers,

Richard