Re: Building packages with exact binary matches
On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote:
> On Wed, 26 Sep 2007 02:45:09 +0200, Martin Uecker <muecker@gmx.de> said:
[...]
> >> > 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.
I am a mathematical phycicist by training: There are no known problems
with the SRT at the small scale. But you are right with your other point:
The math of a scientific theory has to be sound. But it has to be related
to reality, too. It is the last part we are talking about.
> 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.
[...]
> >> 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?
I would assume that there are people hacking on this code or at least
somebody fixes a bug in it occasionally. I know I looked at the
source code of libselinux once (but not closely). If in fact some
code is never looked at, then it is propably a really bad idea to
include it in critical packages.
> > 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.
I never claimed that I believe random people just saying things
are ok or not ok. A binary mismatch is *evidence*. So if some
random people come up with such evidence, then I can check it myself.
> 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.
> > 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.
I do trust that DDs are in gerneral quite qualified and know what
there are doing. But I do not trust the current scheme very
much - not because I do not trust the DDs - but because it
is designed in a way that its security depends on the security
of its weakest link. Binary matches would eleminate a lot of
this fragility
> 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.
Sounds like "Reflections on Trusting trust". But I will look it up.
Martin
Reply to: