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

[Jim Gettys]

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.

So to what standards should one hold squeak vs. gcc?
                              - Jim


On Mon, 2008-06-23 at 15:52 -0300, Jecel Assumpcao Jr wrote:
> Frank Ch. Eigler wrote on Sat, 21 Jun 2008 14:57:52 -0400
> > On Sat, Jun 21, 2008 at 02:50:59PM -0400, Jim Gettys wrote:
> > > > Plus it requires them (and users) to run the tools embedded into the
> > > > possibly suspect image in order to describe itself.  Do you see how
> > > > there could be a trust problem there?
> > > 
> > > Note this is no different than any time you use a compiler binary
> > > provided by someone else...  The attack is just as complete...
> > > http://cm.bell-labs.com/who/ken/trust.html
> > 
> > If that's the best attempt to reassure etoys users/packagers, no
> > wonder the debian people are balking.  The Thompson Trojan is a
> > noteworthy idea, but surely you see the wholly different degree of
> > paranoia we're talking about when we're asked to trust a decades-old
> > virtual machine image as compared to a bootstrappable system.
> 
> I think Jim's point is valid - you have to consider very carefully every
> link in your "web of trust" and understand just how complex it is if you
> want a realistic notion of security. And you have to be clear about your
> needs. As an extreme example: most x86 processors currently have enough
> spare transistors to easily hide an attack similar to the one described
> in the cited paper. I don't think anybody here would spend even a single
> second worrying about Intel or AMD, right? But a person in a country
> that might go to war with the USA might have to think about it.
> 
> Squeak, and Smalltalk in general, represents the opposite extreme in
> that it was mostly developed in that 1970s hacker spirit that gave us
> SMTP and other equally secure systems. And here we run into a common
> problem in the Squeak community: there are those who can (easily, even)
> do something and there are those who feel it is a top priority to do
> that something, but hardly ever there is an overlap between the two
> groups. In the case of security most of the development effort is
> happening in the form of forks rather than changes to Squeak itself, so
> that doesn't help the problem we are discussing at all.
> 
> One way to deal with weak links in a web of trust is to have more
> parallel links. If you have several tools with separate origins then an
> attack that depends on their cooperation will be very unlikely. A tool
> in Python that could investigate a Squeak image file, as has been
> suggested, would be an example of using parallel links.
> 
> About the issue of sourceless objects, this is something that varies
> from image to image. If you start out from some standard image and use
> the paint tool to make a few drawings and open new workspaces and type
> some notes into them then your new image will be more problematic than
> the original. It is likely that with some effort you could have a usable
> image that contained absolutely no objects like this at all. Some other
> Smalltalks have this, which shows it isn't a technical problem.
> 
> So we have two things that should be done: a tool in a language other
> than Smalltalk that can inspect Squeak images and an image which can be
> generated from the sources using that tool. Who will do it? I can't
> think of a name to suggest, which is the problem I mentioned above.
> 
> -- Jecel
> _______________________________________________
> Its.an.education.project mailing list
> Its.an.education.project at lists.lo-res.org
> http://lists.lo-res.org/mailman/listinfo/its.an.education.project
-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child