Stretching out for trustworthy reproducible builds creating bit by bit identical binaries

Welcome and good morning

This is the reproducible builds team,
talking about

"Stretching out towards trustworthy
computing"

[Applause]

We're 4 on stage, but actually this is a
team effort.

All these people listed here have
contributed to the project at one point.

The 4 of us, that's

Lunar − me

there's Dhole,

Chris Lamb − lamby

and Holger.

But actually, this is DebConf and so a lot
more of us have been or are

currently here and so, if you want to
thank anybody that is working on this

you need to actually thank all of
these folks

'cause, yay.

[Applause]

[Holger] The people in blue are here.

[Lunar] Let's get started.

Quick ??? on what we're talking
about.

We have software, it's made from source.

Source is readable by humans or at least
a good amount of humans.

In this room it's good.

Binary, readable by computer and some
tiny fraction of humanity.

Going from source to binary is called
build, or like building or compiling

and we're doing free software and
free software is awesome because

we can actually run these binaries like
we want

We can actually study the software, how
it's been made by studying the source

and by studying the source we can assess
that it does what it's supposed to do

and not something else that does not

have malware, or trojans or security bugs

So we have the binary that can be used,
fine.

We have the source that can be verified.

Problem is that right now, the only way we
know that a binary that we get…

We have to trust a website or a Debian
repository that says

"Well, this binary has been made with this
source"

But there's no way we can actually prove
that.

This is actually a problem that has been
well explained by

Mike Perry and Seth Schoen at the 31c3
in Hamburg last december.

For example, Seth Schoen made a proof of
concept exploit for the Linux kernel

that when GCC was called, the kernel would
without modifying anything on the disk

when the kernel detects that GCC is going
to read a C file, it will insert some

extra lines of code, and these lines of
code can be a very bad thing

in the case of 31c3 talk I was just
recalling.

Actually, you can even have developpers
who are in very good faith, who have

totally secure dev machines, or they
thought they have,

who have reviewed all their source code
for any bugs

and we would still get totally owned as
soon as their computer gets compromised

or one of the build demons from Debian
gets compromised for example.

This is not, like, hypothetical threats
here we're discussing

A couple of months after Seth an Mike's
talk at 31c3,

the Intercept revealed from the Snowden
leaks

that at a CIA conference in 2012, one
of the talks that happened

was about a project called Strawhorse.

Strawhorse is about modifying Apple XCode,
which is the development environment

for MacOS 10 and iOS applications

and well, they were modifying XCode so
it would produce,

without the developer knowing,

binaries with trojans, malware,
??? binaries, lots of bad things.

So, solution:

enable anyone to reproduce identical
binary packages from a given source.

Because if using a source, using the same
environment,

multiple people on different computers, on
different networks, at different times,

can all get the same thing
from the same source

all the same binary, byte for byte,

then there's a good chance that…

Well, everybody could be owned,
but let's be more joyful and say that

probably, if everybody gets the same
result, there was actually no problem

and everybody is safe.

We call that solution
"reproducible builds"

Yay.

[Applause]

Actually, it's not only about security.

For Debian, we have, if you're doing
"Multi-arch: same" packages,

well they only have the same bytes if
they are built for different architectures,

the files in the package.

Debug packages, you can create at a later
time, if you forgot to have debug packages

in the first place,

you can pass the no-strip option later and
because the package is reproducible,

you will get the debug symbols that work
for software that has been shipped already

We do early detection of FTBFS that way

because if we try pretty quickly
to reproduce a build,

then it has to work.