Re: Reproducible builds

2016-07-20 Thread Georg Koppen
Hi, David Bruant: [snip] > Out of curiosity, how has is the TOR team handled points 1 and 2? 1) We remove the .chk files before generating the final package. 2) We have deterministic tar/zip wrappers we deploy, e.g.:

Re: Reproducible builds

2016-07-19 Thread Chris AtLee
Regarding timestamps in tarballs, using tar's --mtime option to force timestamps to MOZ_BUILD_DATE (or a derivative thereof) could work. On 19 July 2016 at 04:11, Kurt Roeckx wrote: > On 2016-07-18 20:56, Gregory Szorc wrote: > >> >> Then of course there is build signing, which

Re: Reproducible builds

2016-07-19 Thread Kurt Roeckx
On 2016-07-18 20:56, Gregory Szorc wrote: 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

Re: Reproducible builds

2016-07-19 Thread Kurt Roeckx
On 2016-07-19 00:49, Mike Hommey wrote: On Sun, Jul 17, 2016 at 09:38:31AM -0700, David Bruant wrote: Out of curiosity, how has is the TOR team handled points 1 and 2? I cannot answer for TOR, but I can answer for Debian, who also does reproducible builds of Firefox. 1) is not addressed

Re: Reproducible builds

2016-07-18 Thread Mike Hommey
On Mon, Jul 18, 2016 at 03:50:38PM -0700, Justin Dolske wrote: > On Sun, Jul 17, 2016 at 9:38 AM, David Bruant wrote: > > > > > The second point sort of solves them both. As part of making things > > verifiable, Mozilla could publish a program that makes byte by byte > >

Re: Reproducible builds

2016-07-18 Thread Mike Hommey
On Sun, Jul 17, 2016 at 09:38:31AM -0700, David Bruant wrote: > Out of curiosity, how has is the TOR team handled points 1 and 2? I cannot answer for TOR, but I can answer for Debian, who also does reproducible builds of Firefox. 1) is not addressed at all, and while the Firefox pack

Re: Reproducible builds

2016-07-18 Thread Justin Dolske
On Sun, Jul 17, 2016 at 9:38 AM, David Bruant wrote: > > 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 >

Re: Reproducible builds

2016-07-18 Thread Ehsan Akhgari
On 2016-07-18 2:56 PM, Gregory Szorc wrote: > 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

Re: Reproducible builds

2016-07-18 Thread David Bruant
Le lundi 18 juillet 2016 20:57:12 UTC+2, Gregory Szorc a écrit : > On Sun, Jul 17, 2016 at 9:38 AM, David Bruant wrote: > > 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 >

Re: Reproducible builds

2016-07-18 Thread Bobby Holley
Yes. Moreover, they are sandboxed at runtime. So modulo bugs in the sandboxing layer, we can treat those blobs as adversarial and the integrity of Firefox shouldn't depend on the integrity of those blobs. On Mon, Jul 18, 2016 at 12:04 PM, Chris Peterson wrote: > On

Re: Reproducible builds

2016-07-18 Thread Chris Peterson
On 7/18/16 11:56 AM, Gregory Szorc wrote: 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. Mozilla does not ship any DRM blobs with Firefox. The Adobe Primetime and Google Widevine

Re: Reproducible builds

2016-07-18 Thread Gregory Szorc
n 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 th

Re: Reproducible builds

2016-07-18 Thread Kurt Roeckx
On 2016-07-17 18:38, David Bruant wrote: 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

Reproducible builds

2016-07-17 Thread David Bruant
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