Reproducible Builds Lightning Talk

Friday, January 29, 16

%&!#*(&!@


Open Source!


Would open source have made this less

likely?


Of course! If anyone is free to audit the code, tricks like this would be caught

(and be less likely to occur in the first place)

except...


Digression: how code becomes software

(compilers and other build tools)

(source code, possibly hundreds of files of varying

types) toolchain

(Software you can use: “apps”, executables, daemons, binaries, libraries, sometimes we’ll refer

to these as “builds”)


You (generally) can’t go backwards

XYou can not verify that a particular application was derived from a particular set of source code.


If you can’t do that, the auditability benefit of (compiled) open source software is a lie.


Instead of certainty, we have trustVendors digitally sign the software they distribute, We trust that the signed build was derived from the corresponding source code.


Build it yourself?Sure... but now you’re trusting the toolchain

Build the whole toolchain, then!You need a toolchain to build a toolchain.


(compromised toolchains are a real thing)


What if a million people, in places and organizations all around the world, built the software, and we compared the results?


Nice idea, but...

• System details, library versions, toolchain versions, file ordering, even timestamps often “leak” into the build process, resulting in builds that aren’t bit-by-bit comparable.

• There’s no way to differentiate this “leakage” from inadvertent or malicious changes.


Are we doomed?


Smart people are working on this!• Recording, sharing, and replicating build

environments (particular toolchain versions and configurations)

• ironing out the sort of “build noise” I mentioned a few slides ago

• The goal being that two builds, of the same software, are bit-to-bit identical

• We can then validate that the software we get from a vendor is built from the source they say it is


Who?


• defining the “buildinfo” file format, and building the tools to support it

• Baking it into the toolchain

• building every package twice, to identify problems related to “timestamps, file ordering, CPU usage, and (pseudo-)randomness”

https://wiki.debian.org/ReproducibleBuilds




Debian’s progress on reproducible builds,10/01/2014 - 1/19/2016


Learn more

• https://reproducible-builds.org/

• https://wiki.debian.org/ReproducibleBuilds


https://reproducible-builds.org/

https://reproducible-builds.org/



Thank you!


Reproducible Builds Lightning Talk

Technology

Transcript of Reproducible Builds Lightning Talk