Re: Building packages with exact binary matches
On Wed, 26 Sep 2007 02:45:09 +0200, Martin Uecker <muecker@gmx.de> said:
> On Tue, Sep 25, 2007 at 06:33:40PM -0500, Manoj Srivastava wrote:
>> On Tue, 25 Sep 2007 23:49:17 +0200, Martin Uecker <muecker@gmx.de>
>> said:
>>
>> > On Mon, Sep 24, 2007 at 06:20:40PM -0500, Manoj Srivastava wrote:
>> >> On Tue, 25 Sep 2007 00:04:15 +0200, Martin Uecker <muecker@gmx.de>
>> >> said:
>> >>
>>
>> >> > It would be enough when just a few people are actually
>> >> > recompiling the binaries and compare it to the official debian
>> >> > packages. Then *everbody* could trust that the packages are not
>> >> > modified, because any modification would be detected
>> >> > immediatley. This is only possible with bit-identical binaries.
>> >>
>> >> Err, what? Why would everyone do that? I mean, you do not trust
>> >> the Debian distribution system, the archive gpg signatures, the
>> >> md5sums on the package, etc, and ye5t you are willing to accept
>> >> mails from other people that things are oK?
>>
>> > No. I would trust the binaries if there are *no mails* from other
>>
>> Ah, security through blissful ignorance :) You do not actually trust
>> the archive, or the developers, you trust the silence.
> I trust special relativity, because nobody has disproven it yet. Do
> you think this is blissfull ignorance, too?
Actually, partly. I am a quantum mechanic by training (I just
went sideways into computer because there was so little money in devoce
modeling). I like the special relativity because the math is sound; it
has predicted things we were not aware of before; and all kinds of
experimental data matches the theory -- except when you get to very
very small dimensions, but people are still working on that.
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.
>> > people that things are *not ok*. Because everybody can check that
>> > the binaries are not compromised, you can actually be quite sure
>> > that things are ok, as long as nobody complains. And if doubts
>> > come up, I can check myself. This actually the same principle on
>> > wich science is build: falsifiability.
>>
>> Everyone does that now based on debian archive signatures. You do not
>> need bit-by-bit verification for that.
> Again: How does this protect against a compromised build host?
Doesn't. So, if the archive signature has not been compromised,
this is a probably a buggy source. Rebuilding from the tainted source
gets you nowhere. But the common case is not this is. Compromised
buildd's are a rare occurrence; and when it is detected, auditing the
sources and rebuilding on a clean machine is a far better solution than
bit for bit same binaries (which is not really much better than the
signed Packages file unless you have a trusted path to the sources,
which you do not.
This lack of a trusted path does the whole let's all rebuild
from source and compare our binaries bit.
>> So, one someone lets the cat out of the bag, and we are not so
>> blissful ,how can we check?
>>
>> Simple, you say, compile the source!! But, dear folks, the person
>> who can compromise the archive, fake out the buildd's, add the
>> archive signature -- can also hack the source.
> Is actually quite likely that somebody would notice if Debian
> distributes trojaned source packages.
Really? What was the last time anyone looked through libsepol
library code, eh? Or libselinux code? You do know dpkg and coreutils
are linked to that?
> All security work in the free software community works like this:
> Somebody finds a flaw, he reports it, it gets fixed. So you say this
> can be DOSed by reporting a lot of false bug reports with a botnet?
No, the bug reporter goes and presents _evidence_ that can be
checked, and a patch, or a source of the problem. No one jumps up and
down and issue CVE's just become someone says things are not ok. And
no one makes a security ssue go away if bunches of people rise up and
say the code is juuust fiiine.
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.
> Ironically, I think the current scheme where the binaries are signed
> by some public key provides a false illusion of security. Have you
> actually thought about the meaning of this signature? It just means
> that the signee (and I do not even know who this actually is) believes
> that this binary was not tampered with. Nothing more. And nobody else
> has the possibilty to verify this.
If you do not know who the signatories of the archive key are, I
suggest you leanr, and see how the web of trust thing works for you,
and whether or not you can trust the guy doing the builds.
Nothing is bullet proof. And no one can make anyone trust
anyone, including themselves. Like all security ractices, it is a
tradeoff. I have decided to trust my fellow DD's, and to trust the
people building the code that runs on my machines. Youe mileage may
vary. But then, you had better know how to write your own assembler in
Hex, and write your own compiler in assembly, and boot strap your
distribution from that.
If you wonder why I say that, ask the mighty internet oracle for
Pike, C compilers, and login.
>> However, this is all moot; unless someone does all the work to make
>> things absolutely bit-for-bit the same, compile after compile, and
>> manages to convince all the package ownsers to accept the changes,
>> this is going nowhere. I am not even sure it can be done,
>> technically.
> You are right: Currently, this is all moot. But I find this discussion
> very interesting.
I am glad to be of service.
manoj
--
Let's do it. Gary Gilmore, to his firing squad
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: