Re: Building packages with exact binary matches
On Thu, 27 Sep 2007 11:28:47 +0200, Martin Uecker <muecker@gmx.de> said:
> On Thu, Sep 27, 2007 at 02:26:49AM -0500, Manoj Srivastava wrote:
>> On Wed, 26 Sep 2007 12:31:51 +0200, Martin Uecker <muecker@gmx.de>
>> said:
>>
>> > On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote:
>>
>> >> Just because you have _heard_ anyone diss special relativity being
>> >> the sole reason to believe in it is in the same ball park as
>> >> blissful, you know, ignorance.
>>
>> > It is not about hearsay. It is about finding an error in a
>> > predictation. And I do not care *who* finds the error. Of course
>> > the predications have actually be checked. So you are right with
>> > your argument, if nobody actually does this, it would be ignorant
>> > to believe in a scientifc theory for the sole reason that nobody
>> > complains. Similar, if nobody recompiles the packages and checks
>> > for mismatches, then silence would in fact not imply that things
>> > are ok. But I question your premise: I have no doubt that some
>> > people would actually recompile packages and compare the hash. Even
>> > if it is not done normally, somebody would do this if doubts come
>> > up for some reason (e.g. some debian hosts are compromised again.).
>> > This alone would actually be worth a lot.
>>
>> But recompiling from what? If you do not get the exact same source,
>> you have no hope of getting the same result.
> I had the impression that Debian distributes the source code from
> which the binaries are actually compiled and not some random
> variation.
Yup, complete with all the trojans in the binary and all.
>> And the way things work, the chances are that if the binary is
>> tainted, the source would be tainted -- and you have got nowhere.
> If I wanted to hide a trojan somewhere I would to it in the binary and
> not in the source code. People actually look into source code on a
> regular basis but they seldom disassemble a binary.
The window of opportunity is small. You have to replace the
binary .deb in between the time it was built, and it was signed.
>> >> The difference is evidence. If there is some merit to the notion
>> >> that a buildd is compromised, the solution is not bunches of
>> >> people building from potentially tainted sources and comparing
>> >> checksums.
>>
>> > If know that the source code wich has hash 4457575757575 compiled
>> > in the build environment with hash 4837373737 gives a package with
>> > hash 366336363, then it is actually *evidence* that something is
>> > seriously wrong if you end up with a package with a different hash.
>>
>> So, someone replaces the binary compiled on the buildd with a fake
>> one, in between the binary being built and it being signed? All the
>> work to get bit-for-bit reproducibility for such a low priority
>> attack vector?
> I do not think it is a low priority attack vector. If I would be a
> cracker and had a rootkit installed on a debian build host it would
> certainly insert a backdoor in ssh everytime it is compiled: Access to
> all debian running computers world wide!
Compromise gcc? I see. So, fro all you know, every copy of gcc
in the world now has the compile trojan into ssh built in, and again,
no way for people peering at bits to see if there is a trojan buried in
there to find out.
> BTW I did some tests and for 'dpkg' the only files which change
> between builds are the manpages and that's just because gzip stores
> the date of the orginal in the compressed file.
This is one of the things, yes. ANy package with a tar archive
would suffer similarly.
manoj
--
The bug starts here.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: