Why trust any software?

[Jean-David Beyer]

On 08/05/2013 06:31 AM, kardan wrote:
> Hi,
> 
> I would like to widen the view of this thread as the question not 
> only apply to windows software in my eyes.
> 
> On Thu, 25 Jul 2013 21:17:43 +0000 atair <atair04 at googlemail.com> 
> wrote:
> 
>> This basically means, that everyone(!) can access, modify and 
>> redistribute the source code of the program (see [2] if you're 
>> interested). There are lots of people (usually volunteers from 
>> all over the wold) who do peer reviews on the sources (and if
>> you start with [2], _you_ can be another one). Therefore,
>> changes that look like back doors are VERY unlikely to find their
>> way in a release, because hundreds of people are looking how the 
>> software evolves and will reject such a patch.
> 
> This is heard very often. How can I check if this is true for a 
> particular piece of software? For the kernel reviews can be
> tracked via LKML but not every code is so popular. How to see how
> many people really read and approved a patch for example? Also the 
> number may not be that relevant than if experienced developers 
> did.
> 
> On Fri, 26 Jul 2013 09:22:32 -0400 "Mark H. Wood"
> <mwood at IUPUI.Edu> wrote:
> 
>> But it takes only one person who can and does do this
>> inspection, to reveal the evil deed.  And that person could be
>> anywhere.  He very likely won't be identified until he announces
>> his presence by announcing his discovery of the attack.
> 
> I would love this person even showing up to approve if there is no
>  attack - just for me feeling better.
> 
> On Fri, 26 Jul 2013 00:14:08 +0200 "Julian H. Stacey" 
> <jhs at berklix.com> wrote:
> 
>> However you missed the point that many MS users are not 
>> programmers, & will not be compiling their own binaries, so any 
>> malign entity could regularly hack their nasty extras in,
>> compile & issue binaries that dont match published source [...]
> 
> Also many linux users look strange at me if I say I do compile 
> parts of my debian system.
> 
If somehow you trust the Linux kernel you are using, that is already a
big assumption.

That would assure you that the Kernel source was used to compile the
kernel. And if all was properly signed, and you have somehow obtained
the fingerprint of the signing key in some reliable way, that would
give high assurance.

But how about the compiler that was used. It could have been sabotaged
too, to insert a back door into any code it compiled, or only code for
files with names that exist in the compiler and a kernel, perhaps.

So not only need you trust the people who examined the source code for
the kernel, you need to trust the people who support the kernel to
have done the same thing for the compiler they use. And the compiler
they used for compiling that compiler.

To really trust (or not trust), you have to take all that C-code for
the first compiler and compile it by hand to binary (not assembly
level). Then use that to make the assembler that has been similarly
verified, then the C compiler you really want to use, and so on.

I am not sufficiently paranoid to do this, and I would not live long
enough to do it even were I motivated to do it. Maybe Ken Thompson or
Dennis Ritchie could do it, but I bet he would not.


-- 
  .~.  Jean-David Beyer          Registered Linux User 85642.
  /V\  PGP-Key:166D840A 0C610C8B Registered Machine  1935521.
 /( )\ Shrewsbury, New Jersey    http://counter.li.org
 ^^-^^ 08:10:01 up 1 day, 23:35, 2 users, load average: 4.49, 4.43, 4.56