Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Slashdot article on MITRE open source software

----- Original Message -----
From: "John Abreau" <jabr at>

> Hash: SHA1
> Content-Type: text/plain; charset=us-ascii
> John Chambers <jc at> writes:
> > Then, of  course,  there's  Ken  Thompson's  famous  "Reflections  on
> > Trusting Trust" paper, in which he explains how to install a backdoor
> > in a program in such a way that it doesn't  appear  anywhere  in  the
> > source,  but  is  inserted  in the binary by the compiler.  Also, the
> > insertion code doesn't appear in the compiler source, but is  in  the
> > binary version of the compiler, even after you recompile it.
> I remember reading that paper back in college. I responded at the time
> that if you write your own bootstrap compiler to compile the "real"
> compiler's source, you'll then have a binary of the "real" compiler
> that doesn't contain the insertion code.
> Today I would add to the rebuttal an assertion that the premise assumes
> a bug-free instance of the insertion code, and one that can successfully
> anticipate any future enhancements and other modifications to the compiler
> source code. I'd even speculate that such an ability might require an
> AI of nearly human-level intelligence, and I doubt such a thing would be
> small enough to insert unnoticed into the newly compiled compiler binary.

Isn't it an academic problem? The invention of public key cryptography, and
the verification checksums it supports, should obviate this.


BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /