Re: [rtcweb] Hermetic builds (Re: Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees)

[Ron <[e-mail]>]

On Mon, Dec 16, 2013 at 05:55:00PM +0100, Bjoern Hoehrmann wrote:
> * Harald Alvestrand wrote:
> 
> As an example, a binary might contain absolute paths to where the debug
> symbol files have been generated during compilation.

That actually raises another interesting point, being whether the people
proposing these blobs have thought about also providing debug symbols for
them, since the lack of that would certainly make problems harder to
diagnose.

It is possible these days to strip those into a separate image from the
runtime library.


> >The bootable image of the build environment may be the simplest way....
> 
> The idea is to avoid trusting binary blobs, so one binary blob producing
> another binary blob is not really interesting. Of course, explaining how
> to create an equivalent bootable image (install Debian vX.Y with default
> options, apt-get build tools, wget source code, untar, configure, make)
> can avoid many problems.

It actually requires much more than that, since any given Debian X.Y is
not definitive about what versions of which packages you may end up with.
Debian potentially has security updates several times a day, so if a
dependency is affected by one of those, you could build a binary that will
not be perfectly reproducible just a few hours later on "the same" X.Y
release of the distro.

There are several options around that, one being http://snapshot.debian.org/
but really you need to document the precise version of everything in the
loop.

And then there were other fun things the tor people found, like locale
being significant for some builds.


I agree that "here's a binary build environment image" doesn't really solve
the problem though -- that just means the paranoid people we're relying on
to be our canaries here need to solve the even bigger problem of figuring
out how to exactly reproduce it first.  As with the question of toolchain
verification, that's probably something we should leave to the OS vendors,
with the paranoids directly keeping them in check -- since there's probably
already plenty to do here just properly specifying the environment needed
for one relatively simple lib.

Ideally this will all eventually be automated, and people can run build
farms independently, that continually verify all the software all the time.
Which is a big part of the reason I'd like to see the people working on
this all get together to build common tools and infrastructure for it.

  Ron