We also had a closely related talk about this at the 31C3 which talks primarily about the motivation for the problem and how the Tor Browser has addressed it (leading into Debian stuff, but the Debian developers couldn&#x27;t join us in person, so you can hear much more about the Debian side from the later talks that the article refers to).<p><a href="https:&#x2F;&#x2F;media.ccc.de&#x2F;browse&#x2F;congress&#x2F;2014&#x2F;31c3_-_6240_-_en_-_saal_g_-_201412271400_-_reproducible_builds_-_mike_perry_-_seth_schoen_-_hans_steiner.html" rel="nofollow">https:&#x2F;&#x2F;media.ccc.de&#x2F;browse&#x2F;congress&#x2F;2014&#x2F;31c3_-_6240_-_en_-...</a><p>I had two examples in that talk that I liked a lot:<p>* What&#x27;s the smallest change that you&#x27;d have to make to a binary to introduce an exploitable vulnerability? (I work through an answer in the talk.)<p>* I demonstrate a kernel module that tampers with source code <i>as it&#x27;s being read by the compiler</i>, so that nothing is modified on disk, and all of the source files are unmodified as confirmed by other software on the system, but the resulting binary is corrupt.<p>You can also hear about my co-presenter Mike Perry&#x27;s heroic efforts to make the Tor Browser build reproducibly, one of the first pieces of open source software of its size and complexity to do so. And definitely one that people are trying to distribute fake modified versions of (not necessarily with network MITMs, though quite possibly -- but even with simple e-mail phishing).