On Sun, Jul 17, 2016 at 9:38 AM, David Bruant <bruan...@gmail.com> wrote:
> Hi, > > Two recent comments on the Linux reproducible build bug thread [1] suggest > that the bug has no clear end goal. > > In this email, I'll try to describe what I understand of the problem and > discuss the outline of a possible end goal. > I felt that the topic covers a wide enough range of responsibilities, so > I'm posting to dev-platform. If there is a better forum, please tell me > what a better forum would be and sorry for the noise. > > # Context > > I believe Brendan Eich's post captures the threat fairly well [2] > > > Every major browser today is distributed by an organization within reach > of surveillance laws. As the Lavabit case suggests, the government may > request that browser vendors secretly inject surveillance code into the > browsers they distribute to users. We have no information that any browser > vendor has ever received such a directive. However, if that were to happen, > the public would likely not find out due to gag orders. > > # End goal > > Brendan Eich suggests : > > > Through international collaboration of independent entities we can give > users the confidence that Firefox cannot be subverted without the world > noticing, and offer a browser that verifiably meets users’ privacy > expectations. > > The end goal would be that someone (EFF or equivalents, security > researchers, etc.) downloads something from > https://www.mozilla.org/en-US/firefox/all/ and can either build a > bit-identical from source or a version that allows to verify that the > downloaded version has not been altered with a backdoor or else. > > The verification could be assisted by a tool that looks at the various > files and verifies the content of important files is bit-identical > > > # Answering to some points > > https://bugzilla.mozilla.org/show_bug.cgi?id=885777#c21 > > > 1) The NSS .chk files are always different (see #c8). > 2) Timestamps of the files inside the .tar.bz2 package will differ, but > untarring them and using a recursive diff will reveal no differences > (except for the aforementioned .chk files) > > The second point sort of solves them both. As part of making things > verifiable, Mozilla could publish a program that makes byte by byte > comparison only on files that matters after unzip. If they're not that > important, .chk files could be ignored (blacklisted from the comparison). > Same for file timestamps. > That would be acceptable IMHO since a backdoor cannot be hidden in .chk > files or file timestamps (right?). > > That could be called "comparable builds" and seems closer to something > reachable than actually bit-equality. > This shifts the problem a bit because another programs verifies Firefox. > However, this verifying program is a combination of gunzip + directory > traversal + bit comparison and seems simple enough that it cannot be the > target of being alterable. > > Out of curiosity, how has is the TOR team handled points 1 and 2? > We already have deterministic packaging in some parts of Firefox (notably most XPIs and omni.ja files). We've done this by implementing our own jar/zip archiving layer ( https://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozpack/mozjar.py) which pins times, sorts files before writing, etc. We just haven't applied this to all parts of packaging yet. We know what we have to do here. > > > https://bugzilla.mozilla.org/show_bug.cgi?id=885777#c22 > > > Docker images are notoriously not very reproducible (because `yum > update/install` installs the latest version of packages advertised on > servers and that can change over time). > > Does this affect file bit-to-bit comparison between what can be downloaded > from https://www.mozilla.org/en-US/firefox/all/ and what can be built > from source? > > > However, paranoid people will want to reproduce those independently. > It's turtles all the way down of course. The question is how far do we want > to go. > > In my opinion, enabling independent organization to point out whether what > can be downloaded from https://www.mozilla.org/en-US/firefox/all/ has > been altered would be an amazing first milestone. > I wouldn't worry too much about "paranoid people" for now. > > > We /could/ publish the Docker images Mozilla uses (they are probably > already public for all I know). > > Publishing the images used by Mozilla would probably be enough for now > IMHO. People can always audit the image by traversing the image file system > to see whether they find something fishy. > > Does a comparable build seems like a good end-goal? > A significant obstacle to even comparable builds is "private" data embedded within Firefox. e.g. Google API Keys. I /think/ we're also shipping some DRM blobs. Then of course there is build signing, which takes a private key and cryptographically signs builds/installers. With these in play, there is no way for anybody not Mozilla to do a bit-for-bit reproduction of most (all?) of the Firefox distributions at https://www.mozilla.org/en-US/firefox/all/. The best we can do is ask you to compare the extracted/packaged files and compare them - modulo pieces like the Google API Key - to what a 3rd party entity has produced. Unfortunately, I'm not sure that will be trivial, as I believe these private blobs of data are embedded within libxul. So your comparison tool would have to know how to read library headers and possibly even assembly code. At some point, the ability to audit a Firefox distribution is undermined enough that a security professional may not feel comfortable saying it looks good. So when I asked what the end goal is, I'm really asking non-Mozilla groups what an acceptable level of reproducibility is. While I agree deterministic, reproducible builds have a number of positive traits (including caching for the build system to make builds faster!), I see enough obstacles for satisfying the intent of security-minded groups that I question whether it is worth doing for those groups alone. Right now, Tor and Debian can both build Firefox in a mostly reproducible manner. And our policy on the build system is that any patches they write to achieve that goal will (likely) be taken upstream. I just don't know if it is worth our effort to work on additional reproducibility efforts given limitations reproducing what *Mozilla* actually ships. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
