[IAEP] etoys now available in Debian's non-free repository

[John Gilmore]

Jim:
> My point is somewhat different: the only way out of the compilation
> trust trap is another compiler.  Unless someone has done this for gcc,
> it has the identical problem, and there are many possible upstream
> attacks.  I see no reason (probably less) to trust the chain of trust
> for gcc than I do Squeak, as the rewards of attacking gcc are so much
> higher.

Alan:
> We are dealing with stories here, not with any kind of reality. 

Here's a story for you.

GCC is regularly compiled with non-GCC compilers.  It has been
bootstrapped thousands of times, using dozens of different compilers
(Sun's, Intel's, Apple's MPW, Green Hills, Code Warrior, MIPS's, ...).
GCC includes lots of hacks and configuration code to allow it to build
on other vendors' buggy or divergent compilers.  I've bootstrapped it
myself hundreds of times, and Cygnus built the testing infrastructure
to do it nightly on many architectures.  The makefiles are set up to
do the classic 3-stage bootstrap:

  stage1 = binaries from GCC sources compiled with vendor compiler
  stage2 = binaries from GCC sources compiled with stage1 GCC
  stage3 = binaries from GCC sources compiled with stage2 GCC

We then make sure that the stage2 and stage3 binaries are identical.
(This check has caught hundreds of bugs in gcc, binutils, and in
vendor compilers.)

(The 3-stage bootstrap does not prevent or detect a Ken Thompson style
all-binary attack -- but to succeed on a particular platform, you'd
have to patch both the vendor compiler and GCC, and keep these patches
in sync over time.  GCC also supports full blown cross-compilation (of
itself and anything else), so a cross-bootstrap from any other host
architecture would break the chain of an all-binary attack.  Debian's
issue is not about resistance to Thompson attacks; this is just an aside.)

It is trivial to build working binaries of GCC from a source tree, if you
have a C compiler from any other source.  "./configure && make install".

This is quite different from the eToys situation, in which there is a
single binary implementation of the language; and the sources, where
present, are all mixed into a binary blob that's only readable by the
single implementation.  I have the same concerns that Debian does.  Is
there even a tool internal to eToys that confirms that everything in a
blob includes the matching source?  Let alone a tool that would
extract that source and rebuild the blob from scratch, using a
virgin binary environment.

We could've bootstrapped GCC once, and limped along ever afterward
with binaries built from that one original GCC binary.  (In a sense,
the entire C compiler market has done this.  Bell Labs' original C
compiler was bootstrapped from a BCPL compiler, and every other C
compiler probably bootstrapped from Bell's C compilers.)  Instead, the
GCC maintainers built lots of infrastructure to allow GCC to be
bootstrapped anytime somebody wants to.  And to test it regularly.
That's the part that eToys hasn't done.

It turns out to be quite hard to reproduce a GCC release or Linux
release, bit-for-bit identical, from its source tree.  If you haven't
tested it, I'd pretty much guarantee that it isn't working.  It has
subtle dependencies on its build environment, which predates the
release.  GCC depends on the binutils, on libc, and on many external
include files, for example.  Even unpacking a source release depends
on tar and gzip or bzip2, each of which depends on the installed
shared libc.  Cygnus was bit by such build-environment dependencies
several times, when trying to produce patches against its old GCC
binary releases.

Are Fedora releases verified before release to build an identical
binary CD/DVD image, starting from only a bare Fedora (release X)
bootable binary CD/DVD, a freshly bought bare PC, and the pile of
source code RPMs in the Fedora (release X) source CD/DVD?  (I think
not -- I don't see source or binaries of pilgrim, which makes the
bootable CD image.)

Are Debian releases tested to reproduce themselves the same way?
Perhaps eToys can get a reprieve until Debian confirms that it,
itself, can do what it asks of eToys.

	John

PS: Several distros don't make it easy to *find* source code releases.
There's no obvious path on http://getfedora.com to get the definitive
F9 source code release; you have to troll around in the mirrors
looking for it.  OLPC will groan when it gets the first letter asking
for the matching sources for its binary (flash) release.  It's only a
few cranky geeks like me who insist on actually obtaining the sources
for their "free" binary software.