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.:
https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/bui
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 takes a private k
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
ht
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 at
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
> > comparison only on files
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 package
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
> important, .chk files could
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
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
> jar/zip archiving layer (
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 7/18/16 11:56 AM, Gregory Szor
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 CD
f 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
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 things
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 responsibil
14 matches
Mail list logo
