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? 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? David [1] https://bugzilla.mozilla.org/show_bug.cgi?id=885777#c21 [2] https://brendaneich.com/2014/01/trust-but-verify/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
