reproducible builds lightning talk

Friday, January 29, 16

%&!#*(&!@

Friday, January 29, 16

Friday, January 29, 16

Open Source!

Friday, January 29, 16

Friday, January 29, 16

Would open source have made this less

likely?

Friday, January 29, 16

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...

Friday, January 29, 16

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”)

Friday, January 29, 16

You (generally) can’t go backwards

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

Friday, January 29, 16

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

Friday, January 29, 16

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.

Friday, January 29, 16

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

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

Friday, January 29, 16

(compromised toolchains are a real thing)

Friday, January 29, 16

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

Friday, January 29, 16

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.

Friday, January 29, 16

Are we doomed?

Friday, January 29, 16

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

Friday, January 29, 16

Who?

Friday, January 29, 16

• 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

Friday, January 29, 16

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

Friday, January 29, 16

Learn more

• https://reproducible-builds.org/

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

Friday, January 29, 16

Thank you!

Friday, January 29, 16