Call for real-world scenarios prevented by RB practices

[John Gilmore]

On 22/03/2022 13.46, 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"?

The GNU compilers are already tested for complete reproducibility.  We
at Cygnus Support built that infrastructure back in the 1990s, when we
made gcc into a cross-compiler (compiling on any architecture + OS,
targeting any other).  We built the Deja Gnu test harness, and some
compiler/assembler/linker test suites, that rebuilt not just our own
tools, but also a test suite with hundreds or thousands of programs.  We
compared their binaries until they were bit-for-bit identical when built
on many different host machines of different architectures.

To make it work, we had to fix many bugs and misfeatures, including even
some high-level design bugs, like object file formats that demanded a
timestamp (we decided that 0 was a fine timestamp).  A few of those bugs
involved generating different but working instruction sequences -- I
recall fixing one that depended on an uninitialized local variable.

We never found any malicious code in the GNU tools during that process,
just poorly debugged code and unportable code.  I don't know whether
that's because nobody malevolent actually knew what a lever they would
have had by infesting our code, or whether we really weren't as
important as we thought we were :-/.  I was still manually making and
reading the diff between the previous release and each new release, to
make sure that no change that I didn't recognize would slip through.  It
was a pretty heady feeling to make a GNU tool release, send an email to
info-gnu, and have thousands of people running it in the next few days.
We took the responsibility seriously.

(Caveat: We weren't shipping binaries, except to Cygnus customers.
 Maliciously patched binaries are what RB is designed to prevent.)

	John