Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Deterministic builds and software trust

Mike Perry mikeperry at
Thu Jun 20 01:34:56 PDT 2013

Jonathan Wilkes:
>  >From: Mike Perry <mikeperry at>
> > [...]
> > This is where deterministic builds come in: any individual can use our
> > anonymity network to download our source code, verify it against public
> > signed, audited, and mirrored git repositories, and reproduce our builds
> > exactly, without being subject to such targeted attacks. If they notice
> > any differences, they can alert the public builders/signers, hopefully
> > using a pseudonym or our anonymous trac account.
> >
> > This also will eventually allow us to create a number of auxiliary
> > authentication mechanisms for our packages, beyond just trusting the
> > offline build machine and the gpg key integrity.
> Interesting.  Questions:
> 1) I'd imagine in your case that a large portion of
> users aren't going to want to compile the software, and it seems at
> least like they could still be good citizens by verifying the binaries
> they download against what a random sampling of mirrors say they
> should look like.  Is there a tool out there they can use to do this?

Right. First, let me say just to make this fully clear: not everybody
needs to compile their own bundles to protect against attack. This isn't
security-through-self-compilation a-la Gentoo.

You only need to compile a bundle if you suspect either nobody else in
the world is privately verifying the bundles (and right now, you might
be correct), *or* if you suspect the GPG keys are compromised and you
specifically are being fed targeted, fake-signed bundles that none of
the private verifiers actually see.

However, I would still like to mitigate even these targeted attacks.
Here's my thoughts so far:

The immediate plan is to publish the full set of detached GPG signatures
for all of the matching public builds to start, so that we at least
require multikey compromise to mount the targeted fake bundle+fake
signature attack. Hopefully at least one of the builders will use a
hardware GPG signing token, to make such theft harder. (It's on my TODO
list to figure that out for my own keys..)

Later, as I alluded to in that next paragraph, we can do
defense-in-depth things like place a URL that lists the approved
official bundle hashes along with a SHA256SUM for that URL's contents in
the Tor Consensus document (which is also a multikey signed document
using offline keys and yearly signing key rotation).

We can also verify the consensus document hash itself (including the
package URL+hash) with a "double Ben Laurie" multipath+notary and/or
multisigned hashtree check...

I would like to do all of these things (especially the "double Ben
Laurie" backup Tor Consensus verification, because I don't really think
we should trust the consensus keys fully as we do now), but there's also
a lot of other things to do at Tor first. Who knows what shiny new
explosion of doom will distract me next. It's an exciting place to work!

> 2) Do you use Tor's git version id (the hash) for the
> release as the random seed string?  Seems like that would be a
> good precedent to set in case other projects start using this
> method, too.

Not sure exactly what you're asking here.

For GCC's -frandom-seed, we just use "tor" as the string. I'm not aware
of any reason why that seed needs to ever change (my understanding is
that it is only used for symbol mangling to avoid static/namespace

We also include the full set of git hashes, version tags, and input
source hashes in the bundles themselves, so you know exactly what went
into your bundle if you want to try to match it at a later date...

Mike Perry

More information about the liberationtech mailing list