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 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?
In Debian we have a similar problem with the timestamps in .deb files.
We're actually making the .deb files bit identical. See
https://reproducible-builds.org/specs/source-date-epoch/ for how that's
done.
A different problem you might have is that the order in .tar.bz2 files
might not be identical, see:
https://wiki.debian.org/ReproducibleBuilds/FileOrderInTarballs
Note that Firefox in Debian can be build reproducible, I'm just not sure
what is all needed for that.
Kurt
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
