Re: Building packages three times in a row
Benjamin A'Lee <bma+lists@subvert.org.uk>:
> On Mon, Sep 24, 2007 at 12:54:58AM +0200, Martin Uecker wrote:
> > Neil Williams <codehelp@debian.org>:
> > > This has been covered before - certain upstream macros are among
> > > many factors that ensure that this is unlikely. I, for one, use
> > > such
> > > macros upstream to indicate the build time of the actual
> > > executable
> > > installed so this will change the binary every time it is built.
> >
> > This could be fixed.
>
> In every binary that includes the build date in it? There's rather a
> lot; off the top of my head, Vim does it, and so does the Linux
> kernel AFAIK.
I know. In a world where providing a correctly working clean
target is already an issue, that's pretty far fetched.
But IMHO being able to recreate binaries from source code in
a reproducable way would be a milestone for security and QA.
> > > You have md5sums and GnuPG signatures on the Release files - I
> > > see no benefit from bit-matching.
> >
> > The build host could be compromised. Not that unlikely.
>
> And if the build host was compromised, how would that help any more
> than md5sums and gpg-signing? With access to the build host, whatever
> list of bits to match could be changed along with the binary, the md5sum,
> and the gpg-signature.
>
> Anyway, surely the point of hashes like md5, sha1, etc, is that it's
> much faster to do that than to compare large files bit by bit?
The idea is not to replace hashes by bit-by-bit comparison, but to
be able to *independendly* reproduce binaries from source code in
a bit-identical way. Then third parties can recreate the binaries
and publish recreated hashes. If the recreated hashes are identical
then you can be sure that nobody has tempered with the build process
and the binary is actually created from the unmodified sources. The
current scheme just protects against tempering after signing. That
is actually not very much.
Martin
Reply to: